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

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

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

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

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

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

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

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

Selektionsvariante "gesperrte" Innenaufträge und Kostenstellen

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

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

Status TABGL und AfA Buchung

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

Plankosten und Istkosten Sperre für Kostenstellen

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

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

Auswertung Kostenstellen und Innenaufträge mit Report Painter

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

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

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

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

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

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

Bei der Suche können folgende Maskierungszeichen verwendet werden:

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

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

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



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


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

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

Im Artikel "Darstellung einzelner Projektphasen von der Freigabe bis zum Abschluss eines Innenauftrags anhand einer Query mit Ausgabe GESPERRT aber auch Abschlussdatum" bin ich auf die unterschiedlichen Status oder Statusse eines CO Innenauftrag eingegangen.

Systemstatus als Lebenszyklus eines CO-OM Innenauftrag

Der Systemstatus bildet dabei den Lebenszyklus eines Innenauftrages von der Eröffnung bis zum Abschluss eines Auftrags/Projektes dar. Dabei sind je nach Status unterschiedliche betriebswirtschaftliche Vorgänge für einen Systemstatus gestattet.

Dabei gibt es vier Status, die im SAP Standard vorhanden sind:

• Eröffnet (Tabellenfeld AUFK-PHAS0)
  Hier ist der Auftrag angelegt, aber es können noch keine Istbuchungen durchgeführt werden.
• Freigegeben (Tabellenfeld AUFK-PHAS1  Freigabedatum AUFK-IDAT1)
  Hier sind fast alle betriebswirtschaftlichen Vorgänge erlaubt
• Technisch abgeschlossen (Tabellenfeld AUFK-PHAS2  Freigabedatum AUFK-IDAT2) TABGL entspricht Systemstatus I0045 TABG
  Hier könenn keine Planänderungen mehr vorgenommen werden aber Istbuchungen sind noch möglich
• Abgeschlossen (Tabellenfeld AUFK-PHAS3  Freigabedatum AUFK-IDAT3) entspricht Systemstatus I0046 Abgeschlossen
  In diesem Status sind keine kostenrelevante betriebswirtschaftlichen Vorgänge mehr erlaubt

Den Lebenszyklus eines Innenauftrages ist in folgender Abbildung in unserem Buch Schnelleinstieg ins SAP Controlling vorgestellt worden.


Einzelne Status eines CO Innenauftrags (Lebensweg eines Innenauftrag)
Spannend dabei ist, dass dieser Lebensweg nicht nur in einer Richtung, sondern auch wieder auf die jeweilige vorherige Stufe (Status) zurück gelebt werden kann.

Eine ausführliche Beschreibung zum Thema CO Innenauftragsrechnung  ist unter Buchempfehlungen unter  Schnelleinstieg ins SAP®-Controlling (CO) – 2., erweiterte Auflage (SAP Modul CO; interne Rechnungswesen) zu finden.

  Paperback ISBN: 9783960120346

Für 29,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Ebook ISBN: 9783960120346
 
 

Anwenderstatus

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 Vorgangssteuerung 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, sodass 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 hinterlegt werden. Jeder diese Statusschemata 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 Ablaufplanes für die einzelnen Phasen eines Projektes welches als Innenauftrag abgebildet wird.

Zusammenhang betriebswirtschaftlicher Vorgang (VRGNG) und Status

Wie bereits erwähnt können zwischen den einzelnen Status innerhalb der Stammdaten von CO Innenaufträgen über die Transaktion KO02 in der Registerkarte Status der Systemstatus und die entsprechenden erlaubte Vorgänge eingesehen und über die Pfeiltasten beim Systemstatus der entsprechende Status gewechselt werden.

Alternativ kann in der Transaktion KO02 über

• (Mehr)
• Bearbeiten
• Anwenderstatus
  • ein gepflegter Anwenderstatus für das CO Objekt (Innenauftrag)
• gesetzt werden oder per
  • Freigabe zurücknehmen (nachdem der Auftrag angelegt wurde)
  • Freigeben
  • Techn. abschließen
  • Abschließen
• ein entsprechender Status gesetzt werden oder
  • Sperre (Setzen) das Objekt gesperrt werden
  • Löschvormerkung (Setzen) der Auftrag zur Löschung vorgemerkt sein.

Insgesamt sind dieses die vorgegebenen Varianten zum Systemstatus, wobei der Anwenderstatus, wie im oberen Absatz beschrieben selbst gepflegt werden kann bzw. hier entsprechende betriebswirtschaftliche Vorgänge hinterlegt werden.

Für den aktiven (gepflegten) Innenauftrag in der Transaktion KO02 kann über

• (Mehr)
• Zusätze
• Erlaubte Vorgänge (UMSCH + F7)

eine Liste der erlaubten Voränge zu den aktuellen Systemstatus aufgerufen werden.

Dazu zählen auch die betriebswirtschaftlichen Vorgänge

• KEP Planeinzelposten schreiben
• KOAP Abrechnung Plan
• KOAS Belastung aus Abrechnung Plan
• RKP1 Planung Primärkosten
• RKP3 Palnung Sekundärkosten
• RKP4 Planung Statist. Kennzahlen

und weitere Vorgänge.

Je weiter der Status fortgeschritten ist, umso weniger VRGNG (Vorgänge) sind am Ende noch gestattet.

So könnte zum Beispiel im Status ABGS (Abgeschlossen) folgende Vorgänge noch erlaubt sein:

• BLOC Sperren
• BAB technisch abschließen
• KBFC Verfügbarkeitskontrolle
• LVMS Löschvormerkung setzen

Besonders interessant ist dabei, dass jeder Status zu setzen ebenfalls wieder ein eigener Status ist.

Im Beispiel wäre vor dem Status ABGS abgeschlossen der Status TABG technisch abgeschlossen zu setzen und entsprechend sind auch die anderen Systemstatus aufeinander aufbauend, wie weiter oben am Lebenslauf eines Auftrags zu sehen ist.

Pflege der Zuordnung von Systemstatus und betriebswirtschaftlichen Vorgang

Über die Transaktion BS22 Systemstatus pflegen oder den dahinter liegenden ABAP Report SAPMBSVB können die einzelnen betriebswirtschaftlichen Vorgänge je Systemstatus gepflegt werden. Dieses sind alle im Paket DSV in der Verantwortung von SAP gepflegt, sodass bei einer Änderung hier darauf geachtet werden muss, dass im Rahmen eines Supportpackage diese Änderung nicht überschrieben wird.

Anhand der Transaktion BS23 Systemstatus anzeigen kann sich im Vorfeld die Einträge erst einmal angezeigt werden.

Die einzelnen betriebswirtschaftlichen Vorgänge können über die Transaktion BS33 Vorgänge anzeigen und BS32 Vorgänge pflegen ebenfalls näher betrachtet werden.

In unseren Fall soll, nach einer erfolgreichen Plankopie der Innenaufträge, auf bereits abgeschlossenen Innenaufträgen noch Planabrechnung und Planumlage für eine Planrechnung durchgeführt werden.

Bisher musste dafür nach der erfolgreichen "Plankopie der Innenaufträge" per Massenpflege die relevanten Innenaufträge entsperrt werden, sodass hier eine Buchung möglich ist. Danach musste per Query wieder festgelegt werden, welche dieser Innenaufträge danach wieder abgeschlossen werden müssen.

Hilfreich war es hier per KOK5 sich eine Liste der relevanten später wieder zu ändernden Innenaufträge, wie im Artikel "Selektionsvariante KOK5 und Statusselektionsschemata zur Auswertung gesperrter Innenaufträge" beschrieben abzuspeichern.

Da diese Änderungen immer wieder erfolgen und auch fehleranfällig sein können, insbesondere wenn die Daten an ein anderes System übertragen werden und dort als nicht abgeschlossen geführt werden, kam die Überlegung auf, ob nicht auch bei abgeschlossenen Projekten Planbelege zugelassen werden können.

Damit wären auch Auswertungen wie "Änderungsbelege zu CDHDR und CDPOST für SAP Objekte wie Stammdaten im Rechnungswesen (Report/Transaktionscode RSSCD100)" nicht mehr erforderlich.

Pflege Betriebswirtschaftlicher Vorgänge für Systemstatus I0046 Abgeschlossen (ABGS) oder I0045 Technisch abgeschlossen (TABG)

Nach Aufruf der Transaktion BS22 erhalten wir eine Übersicht aller im System vorhandener Systemstatus.

Hier kann auf den Eintrag I0046 ABGS abgeschlossen oder I0043 SPER Gesperrt  oder I0045 TABG Technisch abgschlossen  (ggf. muss hier in der Liste etwas geblättert werden) auch  per

• (Mehr)
• Springen
• Vorgangssteuerung

zum jeweiligen Status die einzelnen Betriebswirtschaftlichen Vorgänge per Kennzeichen zwischen folgenden Optionen gewechselt werden.

• Kein Einf
  "Kennzeichen: Vorgang wird nicht beeinflusst"
  Damit hat der Systemstatus keinen Einfluss auf diesen Vorgang
• Erlaubt
  Damit darf dieser Vorgang ausgeführt werden, wenn dieser Status gesetzt ist
• Warnung
  Hier erfolgt eine Warnmeldung, wenn dieser Vorgang durch einen Anwender ausgeführt wird (gelbe Meldung), aber der Vorgang ist weiterhin möglich
• Verboten
  Sofern der Status gesetzt ist, wird auch dieser Vorgang direkt unterbunden (rote Fehlermeldung).

Hier kann also für einzelne Vorgänge (wie oben aufgeführt) zum Beispiel von Verboten auf Warnmeldung für den Vorgang KOAP Abrechnung Plan gesetzt werden.

TR852 Hinweismeldung auf Änderung im Namensraum
Dieses ist allerdings eine Änderung im SAP Namensraum, so dass hier das entsprechende Objekt (Status des Innenauftrages) auch einen entsprechenden Hinweis (Meldungsnummer "TR852 - Führen Sie nur dringende Reparaturen in fremden Namensräumen durch") ausgegeben wird, dass dieses für drigenende Reparaturen und nach Rücksprache oder auf Anweisung des Namensraum inahber (SAP oder Software-Hersteller) erfolgen sollte.

Die hinter dieser Änderung liegenden Tabellen wird von SAP oder den Namensrauminhabender (Softwarehersteller) gepflegt. Eine Änderung ist als Modifikation zu betrachten und muss nach jedem update kontrolliert werden. Es sollte hier also bewust zwischen der BS22  als Modifikation oder der Nutzung eines Anwenderstatus entschieden werden. Der Anwenderstatus muss bewust gesetzt werden (vergleichbar zu SPERR) und wird nicht in der Tabelle AUFK festgeschrieben.
 

Fazit

Auch wenn durch die Anpassung der Systemstatus und Zuordnung von Vorgängen hier nun eine Planung auf eigentlich abgeschlossenen Projekten / Innenaufträgen erlaubt ist stellt sich die Frage, ob diese Abweichung vom Standard auch sinnvoll ist.


Gerade, wenn eine Planwerterfassung sei es zur Planung oder zu Abbildung von CO Budget vorhanden ist öffnet dieses die Möglichkeiten für etwaige Abweichungen.


Im Buch »Berichtswesen im SAP®-Controlling« bin ich ausführlich auf das Thema Berichtswesen im Controlling eingegangen und habe hier auch das Thema CO Budgetierung über Planwerte beschrieben.
  Vielleicht finden sich hier ja auch noch weitere Anregungen für den Aufbau eines Berichtswesens mit SAP nicht nur für CO im Buch.

Eine solche Anpassung sollte daher nicht nur im Controlling sondern auch im Berichtswesen besprochen und untereinander kommuniziert werden. Daneben ist natürlich auch darauf zu achten, dass nach einem Supportpackage Update auch diese Einstellung kontrolliert werden sollte.

Sinnvollerweise gehört dieses dann auch mit auf der Testfallliste, so dass etwaige Abweichungen, wie im Artikel "Änderungen und Nacharbeiten nach Einspielung SAP ERP 6.0 Enhancement Package 8 (EHP 8) insbesondere im CO" direkt auffallen.


Sinnvoll kann es hier sein den Status TABG für technisch abgeschlossen zu ändern, dass hier Planwerte gebucht werden können, so dass anhand des Status und der AUFK ersichtlich ist, dass das Projekt abgeschlossen ist aber sowohl Ist als auch Planwerte noch buchbar sind.

Neben verschiedenen anderen Lösungen bietet das SAP System mit den Modul Public Sector Management (PSM) mit Funds Management (Haushaltsmanagement) und Grantmanagement (Fördermittelmanagement) eine Lösung für die öffentliche Verwaltung. Im heutigen Artikel möchte ich auf die einzelnen Kontierungselemente und Grundlagen zur Nutzung des Haushaltsmanagement (Modul PSM-FM) eingehen. Oberster Knoten im Haushaltsmanagement ist der Finanzkreis (der vergleichbar zum Kostenrechnungskreis im CO ist). Ein Finanzkreis ist einen oder mehrere Buhcungskreise (FI) zugeordnet. Innehrlab des Finanzkreis gibt es dann unterschiedliche Kontierungselemente auf die ich nun eingehen mag.

Aus Sicht des Controlling können die drei wesentlichen Elemente einer passenden Entsprechung im Controlling zugeordnet werden.
 

Kontierungselemente PSM-FM

Element Haushaltsmanegement	entspricht im CO
Finanzposition	Kostenart, Sachkonto
Finanzstelle	Kostenstelle
Fond	Innenauftrag, Projekt

Allerdings gibt es durchaus noch weitere Besonderheiten auf die ich im Einzelnen eingehen möchte.

Die Pflege der einzelnen Stammdaten finden scih im SAP Menü unter:

• Rechnungswesen
• Public Sector Management
• Haushaltsmanagement
• Stammdaten
• Kontierungselemente
  • Finanzposition
  • Finanzstelle
  • Fonds

Finanzposition

Die Finanzposition ist das Gegenstück zum FI-Sachkonto bzw. der CO-Kostenart und werden in einer Stammdatenhierarchie abgebildet. Diesr Stammdatenhierachie kommt bei der klassichen Budgetierung noch einer besonderen Bedeutung zu auf die ich später noch eingehen möchte. Ergänzend zu den Sachkonten/Kostenarten können aber noch weitere Finanzpositionen als Knoten in einer Hierarchie oder zur Budgetierung genutzt werden.

Im Artikel "Grundlagen: Stammdatenhierarchie im Modul CO und PSM insbesondere beim Berichtswesen mit klassischer Budgetierung (Hierarchiebelege)" bin ich ausführlciher auf die Bedeutung der Stammdatenhierarchie eingegangen.

Die Verknüpfung von Sachkonto und Kostenart (unter ERP) ist schon in der Transaktion FS00 ersichtlich (Sachkonto anlegen). Im Sachkonto kann im Register "Erfassung/Bank/Zins" eine Finanzposition direkt im Sachkonto hinterlegt werden. Daher sollte auch bei der Anlage von Buchungskonten folgende Schritte bei der Stammdatenpflege beachtet werden:

1. Finanzposition anlegen
2. Sachkonto anlegen
3. Kostenart anlegen

Mit der Transaktion FMCIA kann eine Finanzpostion als alphanumerischer Wert (24 Zeichen) angelegt werden. Als Grunddaten werden bei der Finanzposition folgende Werte eingetragen. Das Feld Bezeichnung kann mit 20 Zeichen gefüllt werden während für Beschreibung drei Felder mit jeweils 50 Zeichen zur Verfügung stehen.

Durch die Option "Direkt bebuchbar" ist es möglich die angelegte Finanzposition direkt einem Sachkonto zuzuordnen. "Nicht direkt bebuchbare" Finanzpositionen können als Verdichtung (Knoten) innerhalb einer Finanzpositionenhierarchie verwendet werden um hier direkt bebuchbare Finanzpositionen zuzuordnen. Dieses ist allerdings auch mit direkt bebuchbaren Finanzpositionen möglich.

Der Finanzvorgang bildet die betriebswirtschaftlichen Geschäftsvorfälle ab, wodurch Buchungen aus der Finanzbuchhaltung oder der Materialwirtschaft auf die Komponenten des Hauhalsmanagement weitergeleitet werden. Gemeinsam mit Finanzpositionstyp werden hier Einnahmen und Ausgaben unterschieden.

Dieses ist von besonderer Bedeutung, da die Belegzeilen aus anderen Modulen entsprechend fortgeschrieben werden. Anhand folgender Tabelle sind beispielhaft Zuordnungen von Geschäftsvorfällen zu Finanzpositionen ersichtlich.
 

Finanzvorgang

Finanzvorgang	Betriebswirtschaftliocher Geschäftsvorfall
30	Konten die eien Einnahme oder Ausgabe begründen. Dazu zählen auch Anlagen
60,70	Abstimmkonten für Debitoren und Kreditoren  (Forderungen und Verbindlichkeiten)
80, 90	Bank- und Kassenkonten oder auch Scheck- und Bankverrechnungskonten (ggf. können diese auch 80 zugeordnet sein)
50	Verrechnungskonten für buchungskreisübergreifende Vorgäng
40	Verrechnungskonto Wareneingang/Warenausgang (Rechnungseingang)

Der Finanzpositionstyp unterschiedet noch einmal die Werte der Finanzvorgänge nach Einnahmen (2) und Ausgaben (3) bzw. Bestandskonten (1) oder auch Saldenpositioonen (4). Ferner gibt es noch den Finanzpositionstyp 5 als Klärungsbestand.
Dies dient der sachlichen Einordnung der entsprechenden Buchungen.

Ferner kann in der Finanzposition festgelegt werden, ob hier auch "Negatives Budget" in der klassischen Budgetierung gebucht werden kann. Dieses ist im Artikel "Negatives Budget in Public Sector Management Haushaltsmanagement buchen (klassische Budgetierung und BCS)" beschriebn.

Im Abschnitt Hierarchiezuordnung kann dann die "Übergeordnete Finanzpos." in der Standardvariante zugeordnet. Die Standardvariante der alle direkten Finanzpositionen zugeordnet sind ist die Variante 000.  Wird keine übergeordnete Finanzposition angegeben ist die Finanzposition hierarchieunabhängig.

Nicht direkt bebuchbare Finanzpositionen müssen nicht einer Standardvariante zugeordnet werden und können. Diese können Sie, wie auch direkt bebuchbare Finanzpositionen als Gliederung bspw. für alternative Hierarchien verwenden. Beachten Sie dabei, dass nicht direkt bebuchbare Finanzpositionen auch nur nicht direkt bebuchbaren Finanzpositionen zugerodnet werden dürfen.

Über den Reiter "Alternative Hierarchie" kann auch eine alternative Gliederung von Finanzpositionen über Varianten zugeordnet werden. Diese können im Berichtswesen, wie im Artikel "PSM Recherchebericht: Verwendung alternative Finanzpositionshierarchie" beschrieben verwendet werden.

Im Customizing (Transaktion SPRO) kann unter:

• Public Sector Management
• Haushaltsmanagement Öffentliche Verwaltung
• Stammdaten
• Kontierungselemente
• Jahresabhängige Stammdaten
• Jahrsabhängige Stammdaten aktiveren (Programm RFFMMDACT )

sowohl für Finanzstellen als auch Finanzpositionen die Gültigkeit von Finanzpositionen nach Jahren aktiviert werden. Da diese Einstellungen nicht mehr rückgängig gemacht werden dürfen, werden in vielen Systemen sich vorba für eine jahresunabhängige Finanzposition entschieden weorden sein.

Ebenfalls im Customozing des Public Secotromanagement - Haushaltsmanagement Öffentliche Verwaltung kann unter

• Stammdaten
• Finanzposition
• Variante in Fiannzkreis/Geschäftsjahr anlegen

eine alternative Finanzpositionenhierarchie angelegt werden.

Alternativ zur Hierarchie können unter

• Public Sector Management / Haushaltsmanagement /Stammdaten
• Kontierungselemente
• Finanzpositionen
• Finanzpositionsgruppe
  • Anlegen ( FM_SETS_FIPEX1)
  • Ändern ( FM_SETS_FIPEX2)
  • oder per Anzeigen (F_SETS_FIPEX3)

genutzt werden. Diese eignen sich dann zur Auswertung von einzelnen Gruppen in Berichten.

Neben der Auswertung von Stammdaten im Infosystem kann auch SAP Query zur Auswertung von Finanzpositionen oder Gruppen verwendet werden. Die beiden Artikel "Query Kontenplan für Module CO, FI und PSM" und "Auflösen von Stammdatengruppen nach Einzelwerten - Einzelwerte zu Sets" beschreiben dieses näher.

Im Bereich Berechtigungswesen werden im Artikel "SAP BC: Personalkontenberechtigungen" zum Thema Berechtigungsgruppe erläutert. Diese können entsprechend im Feld Berechtigungsgruppe gepflegt werden und werden von hier in die Stammdatentabelle fortgeschrieben.  Im Artikel "Kontenberechtigung bspw. für Personalkosten auf Kostenarten, Sachkonten und Finanzpositionen oder Belagart mit Berechtigungsgruppen sowie Massenänderungen von Berechtigungsfeldwerten mit PFCGMASSVAL" ist die Pflege entsprechender Berechtigungen ebenfalls erläutert worden.

Finanzstelle

Finanzstellen werden ebenfalls in einer mehrstufigen Hierarchie im Haushaltsmanagement angeordnet. Dabei entsprechen die Finanzstellen (vergleichbar zu den Kostenstellen im CO) einen eindeutig abgrgrenzten Verantwortungsbereich bzw. einer organisatorischen Einheit innerhalb eines Finanzkreis der Budget und Kosten/Erlöse zugeordnet werden können.

In den Grunddaten hat die 16-stellige alphanumerische Finanzstelle eine zeitabhängige Gültigkeit und kann hier mit Bezeichnung (20 Zeichen) und Beschreibung (40 Zeichen) gepflegt werden.

Auch bei der Finanzstelle kann eine Berechtigungsgruppe hinterlegt werden. Neben der Zuordnung von Buchungskreis kann auch ein Geschäftsbereich (bspw. zur Abbildung eines Betrieb gewerblicher Art hinterlegt werden. Die damit verbunden Möglichkeiten sind im Artikel "Grundlagen Finanzbuchhaltung - Geschäftsbereiche als mögliche Lösung zur Abbildung eines Betrieb gewerblicher Art (BgA)" beschrieben.

Sollten einzelne Felder der Stammdaten im Haushaltsmanagement bei Ihnen nicht angezeigt sein können diese im Customizing (Transaktion SPRO) unter

• Public Sector Management
• Haushaltsmanagement Öffentliche Verwaltung
• Stammdaten
• Kontierungselemente
• Feldauswahl bearbeiten
• Feldauswahlleisten bearbeiten
• Feldauswahlleisten für .. bearbeiten
  • unter anderen für Finanzpositionen,
  • Finanzstellen,
  • und Fonds

als Ausblenden, Anzeige, Kanneingabe oder Mußeingabe ausgesteuert werden.

Ein wichtiger Punkt ist noch der "Vorschlagswert Fonds". Der hier hinterlegte Fond wird automatisch beim Bebuchen der Finanzstelle herangezogen sofern beim Buchungsbeleg kein anderer Fond angegeen ist.
Dieser Wert kann entweder leer bleiben "Fond BLANK" oder aber bspw. ein Fond für Haushaltsmittel des Wirtschaftsplan WIPLAN hinterlegt werden.

Unter Hierarchie kann auch für die Finanzstelle eine übergeordnete Finanzstelle hinterlegt werden. Ferner können noch Adresse und Kommunikationsdaten der Verantwortlichen der Finanzstelle hinterlegt werden.
Auch bei den Finanzstellen ist das Arbeiten mit Gruppen unter

• .../ Finanzstelle
• Finanzstellengruppe
  • Anlegen (FM_SETS_FICTR1)
  • Ändern (FM_SETS_FICTR2)
  • Anzeigen (FM_SETS_FICTR3)

möglich.

Wie erwähnt werden bei Finanzstellen und Finanzpositione Hierarchien genutzt die unter anderen auch bei Budgetbelegen bebucht werden. Sofern Sie eine Finanzstellenhierarchei ändern wollen (Finanzstelle/Hierarchie/Bearbeiten Transaktion FMSD) müssen die im Artikel "Reorganisation von Finanzstellenhierarchien" erwähnten Schritte insbesondere zum Neuaufbau der Budgetbelege durchgeführt werden.

Sollten Sie eine nicht mehr benötigte Finanzstelle (oder auch Fond) löschen wollen, beachten Sie bitte die Hinweise im Artikel "Grundlagen: CO-OM Kostenstellen und EC-PCA Profitcenter im Controlling und PSM-FM Finanzstelle im Haushaltsmanagement löschen".

Fond

Ein Fond gibt ebenso wie ein Projekt oder Innenauftrag im Controlling die Antwort auf die Frage, wofür und woher Gelder im Haushaltsmanagement genutzt werden. Dieses sind Finanzmittel die ein Geldgeber für einen bestimten Zweck zur Verfügung gestellt hat und die getrennt von den Miteln auf Finanzstellen verwaltet werden sollen. Eine besondere Bedeutung ist dabei den Fond WIPLAN oder "" zuzuordnen, der den Finanzstellen zugeordnet ist, welche dann auch im Berichtswesen einer besonderen Bedeutung zukommt.

Mit der Transaktion FM5I kann ein 10 stelliger alphanumerischer Schlüssel als Fond angelegt werden. Die Bezeichnung (20 Zeichen) und Beschreibung (40 Zeichen) ist schon einmal eine ausführlichere Beschribung der einzelnen Fonds.

Im Abschnitt Grunddaten kann eine Gültigkeit sowie die bereits erwähnte Berechtigungsgruppe hinterlegt werden. Ferner kann eine Fondsart im Fond hinterlegt werden. Diese können für Reportingzwecke als Merkmal entsprechend gegliedert werden. So steht dieses ebenso wie Debitor zum Fond als Merkmal für Rechercheberichte zur Verfügung.

Die einzelnen Fondsarten wie Drittmittel, Sondermittel oder auch Eigenmittel und Fremdmittel können im Customizing (Transaktion SPRO) unter

• Public Sector Management
• Haushaltsmanagement Öffentliche Verwaltung
• Stammdaten
• Kontierungselemente
• Fonds
• HHM-Fondsarten anlegen

als 6-stellige alphanumerische Schlüssel mit einer Bezeichnung angelegt werden.

Unter den Zusazdaten kann ein Budgetprofil, Debitor zum Fonds und ein Finnazierungszweck hinterlegt werden.

Das Budgetprofil ist nur beim Einsatz der klassischen Budgetierung relevant und ist bei der Nachfolge BCS nicht relevant (siehe Artikel "PSM Haushaltsmanagement Budgetverwaltungssystem BCS oder klassische Budgetierung").

Im Customizing (Transaktion SPRO) kann unter

• Public Sector Management
• Haushaltsmanagement Öffentliche Verwaltung
• Klassische Budgetierung
• Budgetprofile
• Budgetprofiele einstellen

zum jeweiligen Budgetprofil eingestellt werden, über welchen Zeithorizont eine Budgetierung erfolgt (in die Veragngenheit und in die Zukunft) und ob hier Budgetwerte als Gesamtwerte, Jahreswerte oder auch als Periodenwerte erfolgen kann.

Die klassische Budgetierung ist kurz im Artikel "SAP PSM-FM klassische Budgetierung mit unterschiedlichen Budgetversionen" angesprochen worden.

Sofern es zum Fond nur einen Geldgeber gibt kann im Feld "Debitor zum Fonds" ein Geldgeber (Debito) aus der Debitorenbuchhaltung hinterlegt werden. Dieser muss zuvor in der Finanzbuchhaltung als Geschäftspartner/Debitor angelegt sein. Ein Debitor kann dabei in mehreren Fonds hinterlegt werden, alleridngs kann jeder Fond nur einen Debitor zugeordnet werden.

Gerade bei Berichten ist daher die Möglichkeit der Pflege eines Finanzierungszweck im Fond die flexiblere Variante. Im Artikel "PSM-FM Grundlagen Finanzierungszweck im Haushaltsmanagement bei Recherchebericht und Selektion"  oder auch "Grundlagen: PSM-FM Finanzierungszweck (FMFINCODE-FINUSE) im Hochschulberichtswesen für Drittmittelstatistik" ist die Pflege und Auswertung von  Finanzierungszwecken im Haushaltsmanagement beschrieben.

Die einzelnen Finanzierungszwecke können mit SAP Query auch als Gruppierungsmerkmal verwendet werden. Im Artikel "Gruppierung von Finanzierungszwecken bei Drittmittelprojekten per Zusatzfeldcoding mit IF oder CASE" ist hier ein passender Anwendungsfall beschrieben.

Sollten die beschriebenen Daten noch nicht für eine Information zum Fond ausreichen bietet sich auch die Klassifizierung an in der mehrere kundeneigene Merkmale zum Fond als Stammdatum gepflegt werden können.

Im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM"  ist ein kurzer Exkurs zum Klassensystem und Klassifizierung zu finden.


Im Buch »Berichtswesen im SAP®-Controlling« bin ich ausführlich auf dies Thema eingegangen.
  Vielleicht finden sich hier ja auch noch weitere Anregungen für den Aufbau eines Berichtswesen mit SAP nicht nur für CO im Buch. Zumindest ist die Vorgehensweise hier identisch :-).

Integration mit anderen SAP Modulen

Zur Integration mit anderen SAP Modulen können Ableitungsregeln mit der Transaktion FMDERIVE im Customizing des Moduls PSM-FM vorgenommen werden. Diese ist im Customizing (Transaktion SPRO) unter:

• Public Sector Management
• Haushaltsmanagement Öffentliche Verwaltung
• Stammdaten
• Zuordnungen zu Kontierungen aus anderen Komponenten
• Kontierungsableitung definieren

zu finden.

Hier kann eine eigene Ableitungstrategie im Haushaltsmanagement definiert werden und entsprechende Ableitungen wie FOND aus CO-Innenauftrag als direkte Ableitung oder in Form von Tabellen als Sonderfälle (zum Beispiel wenn bestimmte Innenaufträge als Landesmittel direkt den Fond WIPLAN zugeordnet werden als "reine CO Aufträge") definiert werden.

Gerade für das Controlling ist nach einen Doppelklick auf die Ableitungsstrategie und Darstellung der einzelnen aktiven Schritte mit Ableitungsregeln die Schaltfläche Testen (F8) Interessant.

Über das nun vorhandnee Fenster HHM-OObjektzuordnung testen - Ableitungsstrategie können einzelne Objekte eingetragen werden und durch Ableiten überprüft werden, ob die Kontierungsfindung problemlos funktioniert. Ebenfalls ist hier ein Protokoll der Ableitung zu finden. Alternativ kann auch ein Trace zum User aktiviert werden und dadurch die Ableitungen nachvollzogen werden.

Neben anderen Objekten testet die Objektzuordnung:

• Organisationsobjekte
  • wie Finanzkreis, KostRechKreis, Buchungskreis, Geschäftsbereich, Werk, ...
• FI/MM Objekte
  • wie Anlage, Sachkonto, Material, ...
• CO/SD-Objekte
  • wie Kostenart, Kostenstelle, Auftrag, Profitcenter
• Immobilienobjekte
• HHM/FMM Kontierung
• Mittelvormerkungen
• ...

Dabei werden jedoch nur die Regeln der FMDERIVE und nicht der anderen Module (wie bspw. Ableitung des Profitcenter aus den CO-OM Objekten getestet.

Als Regeln können hier einzelne Definitionen bspw. aus Tabellenzugriffe (wie die verantwortliche Kostenstelle aus einen CO Innenauftrag) definiert werden und danach als Quellfelder entsprechenden Zielfeldern im Haushaltsmanagement zugeordnet werden.

 

Berichtswesen im Public Sector Management

Über die einzelnen Kontierungselemente kann im Bereich des Haushaltsmanagement ein Berichtswesen aufgebaut werden.

Insbesondere die flexible Gestaltung von Rechercheberichten, wie im Artikel "»Rechercheberichte de lux« im Modul PSM FM Haushaltsmanagement" bishin zu "Mehrjahresvergleich im Recherchebericht mit Beschränkung von Aufwand und Ertrag für das laufende Geschäftsjahr bis aktuelle/selektiere Periode/Jahr und komplette Perioden der Vorjahre sowie übertragene Jahresendsalden" oder auch Mehrjahresvergleich im "Recherchebericht mit Beschränkung von Aufwand und Ertrag für das laufende Geschäftsjahr bis aktuelle/selektiere Periode/Jahr und komplette Perioden der Vorjahre sowie übertragene Jahresendsalden" bieten hier einige Möglichkeiten das eigene Berihctswesen umfangreich zu gestalten.

Beim Blick auf "Grundlagen Rechercheberichte Ausgabeart grafische Berichtsausgabe oder klassische Recherche" ist auch ausführlich auf die Gestaltungsmöglichkeiten der Berichte eingegangen worden.

Wie geht es mit PSM-FM unter S/4 HANA weiter

Auch unter SAP S/4HANA wird es weiterhin das Modul Public Sector Management geben, allerdings wird hier verpflichtend die Umstellung der klassischen Budgetierung auf das neue BCS (Budget Controll System) erforderlich.

Beim Vergleich der Funktionen der klassichen Budgetierung  und des Budgetverwaltungssystem fällt direkt auf, dass unter BCS keine HIerarchien in den Budgetwerten mehr vorhanden sind. Dieses bedeutet, dass die Budgetbelege nicht mehr innerhalb der Finanzpositionen- und Finanzstellen- Hierarchie gebucht sind sondern direkt auf Finanzstelle, Finanzposition, Foond (und optional Funktionsbereich). Als neue Kontoerungselemente unter BCS sind Haushaltsprogramm und Förerung hinzugekommen. sowie dei Definition von Kennzahlen wie aktuelles Budget. Neben SAP Schulungen zum Thema Public Sector Management kann ich folgendes Buch aus Überzeugung empfehlen.
  (28. Dezember 2015)
Für etwa 79,90 € bei Amazon bestellen


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

Ähnlich wie die Einführung von Geschäftspartner (Business Partner) im FI kann der Wechsel von der klassichen Budgetierung auf das Budgetverwaltungssystem (BCS) ein Vorprojekt wie die Einführung des neuen Hauptbuchs vor der Migration in Richtung SAP S/4HANA sein.

Da sowohl BCS als auch die klassiche Budgetierung hier beschrieben sind dürfte das Buch auch unter S/4HANA und der Nutzung von PSM weiterhin aktuell bleiben.

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

Kundeneigene Zusatzfelder per Custumer-Exit (CMOD)

Konkret handelt es sich dabei um die Kundenerweiterungen:

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

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

Zusatzfelder in Stammdatentabellen CI für AUFK und CSKS

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

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

Customer Include Stammdaten

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

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

Zusatzfelder in Stammdaten Kostenstelle und Innenauftrag

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

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


  Paperback ISBN: 9783960120346

Für 29,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

oder bei Amazon (Print, eBook)
 

Stammdatenlisten KS13, KOK3 und KOK5 mit Zusatzfeldern

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

Im SAP Menü unter

• Rechnungswesen
• Controlling

kann für Kostenstellen

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

und für Innenaufträge

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

eine ALV Liste über die CO Objekte aufgerufen werden.

Alternativ können die Stammdatenberichte auch über

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

aufgerufen werden.


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

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

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

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

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


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

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

Auswertung der Zusatzfelder per SAP Query (Transaktion ZKOK5)

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

Die Datengrundlage als Infoset entspricht folgender schematischen Darstellung:



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

1. Anpassung Infoset

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

• Zusatzfelder CO Innenauftrag
• Zusatzfelder CO Kostenstelle

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

2. Anpassung Query

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

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

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

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

• (Mehr)
• Springen
• Feldauswahl
• Selektion

Die Selektionsmaske für die einzelnen Felder angepasst werden.

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

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

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

Fazit

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

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

Exkurs Datenmigration nach SAP S/4HANA

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

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

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

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

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

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

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

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

---

Hinweis:

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

---

Das Thema Datenmigration unter S/4HANA wird nicht nur im Rechnungswesen sondern auch in anderen SAP Komponenten relevanter. Im Artikel "Fragen und Antworten zur Datenmigration nach SAP S/4 HANA mit LTMC und LTMOM - 📚 Buchveröffentlichung zum SAP S/4HANA Migration Cockpit" bin ich schon auf die ein oder andere Fragestellung eingegangen.

Eine der wichtigsten Fragen, gerade auch von der SAP Basis (BC), dürfte sein, wie vorgegangen werden kann, wenn ein passendes Migrationsobjekt "noch" nicht vorhanden ist.

Migration von Benutzerstammdaten und Rollenzuweisungen unter S/4HANA mit LTMC

Ausgangslage
Unter SAP S/4 HANA ist eine Massenpflege von Benutzer und Rollenzuweisungen geplant. Hier stellt sich die Frage, ob nicht durch das Migrationscockpit als Alternative beziehungswesie Nachfolge der LSMW möglich ist.

Lösungsansatz:
Die seitens SAP als "verfügbaren Migrationsobjekte" gepflegten Objekte haben derzeit ihren Schwerpunkt im Bereich Rechnungswesen und Logistik wie auch anhand der Tabellen der Migrationsobjekte für die On-premise  aber auch Cloud Version von SAP S/4HANA zu sehen ist (siehe "SAP Help Portal: Verfügbare Migrationsobjekte").

Unter SAP ERP hätte ich nun eine Transaktionsaufzeichnung mit eCATT oder auch der bisherigen Methoden wie LSMW vorgeschlagen (siehe Beitrag "Massenstammdatenpflege mit LSMW oder SECATT dank Transaktionsaufzeichnung - Handbuch erweiterte computergestützte Test-Tool (eCATT) und LSMW") aber in der OnPremise Version von S/4HANA ist es dank des Migrationsobjektmodellierer (Transaktion LTMOM) möglich auch eigene Migrationsobjekte anzulegen.

Das grundsätzliche Vorgehen habe ich im Kapitel 4 »SAP S/4HANA Migrationsobjekt-Modellierer« beschrieben.


  Paperback ISBN: 9783960120179

Für 29,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

oder bei Amazon


An dieser Stelle möchte ich daher nur auf den vorgeschlagenen Lösungsansatz eingehen und hoffe, dass dieser auch weiter geholfen hat.

Eigenes Migrationsobjekt mit LTMOM anlegen

Bei der Anlage eines Migrationsobjekt unterscheiden wir zwischen:

• Quellstruktur: Hier dürften Dateien als Quelle häufig gewählt weden
• Zielstruktur: Hier wird definiert wohin die gelieferten Daten gesetzt werden.

Dabei kann die Zielstruktur über ein Funktionsbaustein (FUMO) definiert werden. Damit ein Funktionsbaustein als Basis für ein Migrationsobjekt genutzt werden kann, hat dieser folgende Anforderungen zu erfüllen:

Aufbau eines Funktionsbausteins für Migrationsobjekte

Die zur Versorgung bestimmter Tabellenfelder (bspw. die USR* Tabellen) hinterlegten Funktionsbausteine müssen folgende Anforderungen erfüllen:

• Die Steuerung des Funktionsbausteins erfolgt über das Migrationscockpit (LTMC), alle Meldungen (Fehler und Hinweise) müssen im Format BAPIRET2 als Tabelle oder Struktur zurückgegeben werden.
• Sofern eine Simulation der Datenmigration ebenfalls geplant ist muss auch ein Merkmal zur Verfügung gestellt werden, damit eine Simulation der Dateneinspielung innerhalb der Dateneinspielung erfolgen kann, bevor die Daten in dei Datenbank geschrieben werden.

Funktionsgruppe S_USER und passende Funktionsbausteine

Ein Blick auf passende Funktionsbausteine für die Benutzer und Berechtigungsmigration hat als passsenden Funktionsbaustein BAP_USER_CEATE1 ergeben. Hier sind dann tatsächlich alle Felder eines Benutzerstammsatzes enthalten.

Allerdings fehlt hier die Zuordnung von Rollenzuordnungen. Diese Massenpflege kann dann mit der Transaktion SU10 erfolgen.

Alternativ könnte ein zweites MIgrationsobjekt auf Basis des Funktionsbaustein BAPI_USER_ACTGROUPS_ASSIGN "Benutzer-Rollenzuordnung ändern" verwendet werden.

Beide Funktionsbausteine in Kombination wirken auf mich so, als wäre es hier möglich die Zielstruktur (sprich das SAP System) mit passenden Daten aus einer Quellstruktur zum Beispiel zwei XML / Excel Templatedateien zu versehen.

Fazit

Die erwähnte Vorgehensweise war nun nur ein Lösungsansatz aber ich bin neugierig, ob dieses dann auch im konkreten Anwendungsfall funktioniert hat. Auf den ersten Blick sahen die verfügbaren Datenfelder allerdings passend aus und ich würde mich freuen, wenn auch SAP Basis hier von der Neuerung profitieren wird.

Für einen vergleichbaren Fall unter SAP ERP haben wir vor einigen Tagen die Transaktion SU01 aufgezeichnet und auch im Rahmen einer LSMW/eCATT/Datenmigrationsschulung wird dieser Anwendungsfall als Beispiel sicherlich ebenfalls aufgegriffen :-) und ich bin froh, dass übers Blog aber auch per eMail immer einmal wieder neue Themenvorschläge und spannende Fragen zugesandt werden, aber auch sonst der Austausch rund um SAP und künftig auch S/4HANA wie selbstverständlich gelebt werden kann.

Weitere Artikel zum Bereich SAP Basis und Berechtigungen

Besonders im Bereich Basis (BC) und Berechtigungen sind immer wiederkehrende Aufgaben durch SAP praktisch unterstützt. So kann die Berechtigungsanalyse (siehe Artikel "SAP Basis Basic oder dank SU53 oder ST01 Trace fehlende Berechtigungen finden" insbesondere mit STAUTHTRACE) oder auch die Grundlage für Berechtigungen (siehe "Die Anatomie der SAP Berechtigung oder Dokumentationen zu SAP Berechtigungsobjekten und Berechtigungsfeldwerten")  sowie speziele Anforderungen wie die Massenpflege von Sammelrollen (siehe "SAP Berechtigungen Massenpflege Einzelrollenzuordnungen in Sammelrollen per Funktionsbaustein (FuBa) oder Transaktionscode") und natürlich Massenpflege von Berechtigungsobjekten und Berechtigungsfeldwerten ("Kontenberechtigung bspw. für Personalkosten auf Kostenarten, Sachkonten und Finanzpositionen oder Belagart mit Berechtigungsgruppen sowie Massenänderungen von Berechtigungsfeldwerten mit PFCGMASSVAL") und der Massenupload von Rollen ("Nach der Massenpflege von Berechtigungsobjekten (PFCGMASSVAL) folgt der Massendownload von Rollen (PFCG_MASS_DOWNLOAD)").

Daneben arbeiten SAP Basis und Modulverantwortliche ebenfalls eng zusammen, was auch an Analysen von Änderungsbelegen wie im Artikel "Änderungsbelege zu CDHDR und CDPOST für SAP Objekte wie Stammdaten im Rechnungswesen (Report/Transaktionscode RSSCD100)" beschrieben zu lesen ist.

Neben zeitlich befristeten Controllingobjekten, wie beispielsweise Innenaufträge im Gemeinkostencontrolling (CO-OM), das ich im Artikel »Grundlagen: CO Innenauftrag im Controlling und PSM-FM Fond im Haushaltsmanagement löschen« beschrieben habe, ist es manchmal auch erforderlich eine fehlerhaft angelegte Kostenstelle und entsprechend dazugehörige abgeleitete Objekte (wie Profitcenter oder Finanzstellen) zu löschen.

Gerade durch Themen wie die Mitbuchtechnik und die Überleitung von Buchungen von FI nach CO oder auch in das Modul PSM-FM helfen mir oftmals kleine Kochrezepte in denen einzelne Schritte die zu beachten sind ebenfalls festgehalten werden. Daneben kann natürlich auch Literatur etwas weiter helfen, wobei ich hier gerne gerne auf die Neuauflage  unseres gemeinsames Buch zum Thema Schnelleinstieg ins SAP Controlling (CO) verweise wo die Grundlagen des Controlling mit SAP festgehalten sind.

  Paperback ISBN: 9783960120346

Für 29,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Ebook ISBN: 9783960120346
 

Unter anderen zum Festhalten solcher Punkte nutze ich nun seit etlichen Jahren auch dieses Blog. Ausserdem sollen diese Artikel auch hin und wieder im Arbeitsumfeld nützlich sein :-).

Da auch hier einige Punkte zu beachten sind, möchte ich hier im Artikel kurz auf die wesentlichen Punkte eingehen. Im Artikel "Workflow Kostenstelle und Innenaufträge (Module CO, PSM)" bin ich auf die einzelnen Schritte zur Anlage einer Kostenstelle vom Profit-Center bis hin zur Finanzstelle im Haushaltsmanagement eingegangen.

1. Löschen einer Kostenstelle (CO-OM)

Beim Versuch eine Kostenstelle in der Stammdatenpflege zu löschen kann es zu einer Fehlermeldung kommen, dass diese noch an anderer Stelle genutzt wird, obgleich keine Buchungen (im Ist oder Plan) auf der Kostenstelle vorhanden sind. Dieses liegt daran, dass beim Löschen von Kostenstellen in der Transaktion KS02 oder KS03 über Kostenstelle-> Löschen geprüft wird, ob die Kostenstelle in Aufträgen, Zyklen oder Abrechnungsregeln genutzt wird.

Im Artikel "Grundlagen: Wohin mit den Kosten? Leistungsverrechnung, Kostenverteilung und Kostenumlage im SAP CO-OM." sind einige dieser Fälle erläutert worden.

Die Pflege der Stammdaten von Kostenstellen erfolgt im SAP Menü unter:

• Rechnungswesen
• Controlling
• Kostenstellenrechnung
• Stammdaten
• Kostenstelle
• Einzelbearbeitung

Daher ist es hilfreich in der Transaktion KS02 oder KS03 über

• Umfeld
• Verwendungsnachweis
• Gesamt

prüfen zu lassen, ob die Kostenstelle in einer der möglichen Arten verwendet wird.

Hier werden allle (ebenfalls einzeln überprüfbare Fälle seitens des SAP System überprüft. Dieses sind im Einzelnen:

1. Splittungsschema
2. Leistungsarten
3. Zyklen im CO-OM
4. Zyklen im CO-PA
5. CATS-Überleitungen
6. Abrechnungsregeln
7. Aufträge
8. Projekte
9. Anlagen
10. und GESAMT

In unserem Fall  wird unter ZYKLEN IN CO-OM angegeben in welche Verrechnungsart (bspw. Umlage) und über welchen Zyklus und Segment die jeweilige Kostenstelle verwendet wird.

Gerade wenn es sich nicht um Sender und Reciever (Sender und Empfänger), sondern um entsprechende Set (Kostnestellengruppen) mit zugeordneten Intervallen handelt muss diese Kostenstelle erst einmal aus dem Intervall entfernt, werden bevor die Kostenstelle gelöscht werden kann.

Dieses ist dann wie erwähnt über KOSTENSTELLE -> LÖSCHEN in der Transaktion KS02 oder KS03 (oder per Tastenkombination UMSCH + F2) möglich oder alternativ direkt über die Transaktion KS04.

2. Löschen eines Profitcenter (EC-PCA)

Ebenso ist nun beim Löschen eines Profit-Center zu verfahren. Auch hier kann mit der Transaktion zur Pflege der Stammdaten über Stammdaten (KE51, KE52 oder KE53) direkt die Funktion PROFITCENTER->LÖSCHEN oder mit der Transaktion KE54 direkt ein Profitcenter gelöscht werden.

Im SAP Menü sind die Funktionen unter

• Rechnungswesen
• Controlling
• Profit-Center-Rechnung
• Stammdaten
• Profit Center
• Einzelbearbeitung

zu finden.

Vorher empfiehlt es sich auch beim Profitcenter über die Stammdatenpflege (KE52, KE53)

• SPRINGEN
• ZUORDNUNGSÜBERSICHT

bzw. der Transaktion 1KE4 zu prüfen ob das Profitcenter nicht direkt schon einem CO Objekt zugeordnet ist.

Hier kann in der Transaktion 1KE4 zum Report SAPMKEC4 die Report Variante "Objekte zu PrCtr / PrCTR-Gruppe anzeigen" gewählt werden und nun anhand der Zu prüfenden Objekten geprüft werden, ob hier das zu löschende Profitcenter zugeordnet ist.

Als Objekte stehen folgende Objekte zur Verfügung.

1. Aufträge
2. Geschäftsprozesse
3. Kostenstellen
4. Kostenträger
5. Materialien
6. Projektstrukturpläne
7. Kundenauftragspositionen
8. und Immobilienobjekte (RE-FX)

Je nach eingesetzten Modulen sind entsprechende Prüfungen sinnvoll. Nach Ausführung kann nun dieses noch weiter differenziert werden (bei Aufträgen bspw. nach Auftragstyp und Auftragsart (diese ist obligatorisch) und Profitcenter-Gruppe oder Profitcenter.

Ist keine Zuordnung vorhanden kannd as Profitcenter mit der Transaktion KE54 gelöscht werden.

Dieses funktioniert über die Schaltfläche "Zum Löschen kennzeichen" in der Tansaktion KE54 und danch über AKTIVIEREN, so dass das Profitcenter wirklisch gelöscht wird.

Dieses muss dann noch einmal bestätigt werden, da es sich hier um einen kritsichen Vorgang handelt.

Wurde das Profitcenter in der Vergangenheit verwendet, ist es sinnvoller die Gültigkeit des Profitcenters zu ändern, um hier den Existenzzeitraum des Profitcenters zu ändern.
 

3. Finanzstelle löschen (PSM-FM)

Das Gegenstück zur Kostenstelle im Bereich des Public Sector Management / Haushaltsmanagemen (Fundsmanagement) (PSM-FM) ist die Finanzstelle.

Die Stammdatenpflege ist unter

• Rechnungswesen
• Public Sector Management
• Haushaltsmanagement
• Stammdaten
• Kontierungselemente
• Finanzstelle
• Einzelbearbeitung

zu finden.

Hier kann die Löschung über die Transaktion FMSB und die SChaltfläche LÖSCHEN erfolgen. Auch bei der Finanzstelle gibt es die Option UMFELD->WHERE USED LIST über die Ableitungsstrategie der FMDERIVE aufgerufen werden kann. Anhand der Liste der auf dem Ableitungswerkzeug zugeordneten Objekte ist es nun möglich, in welchen Regeln diese Finanzstelle ggf. ebenfalls verwendet wird.

Das Löschen muss ebenfalls bestätigt werden und die Finanzstelle ist, wie Profitcenter und Kostenstelle ebenfalls Geschichte.

Fazit

Auch das Löschen von Stammdaten wird im SAP System protokolliert. Entsprechende Auswertungsmöglichkeiten sind im Artikel "Änderungsbelege zu CDHDR und CDPOST für SAP Objekte wie Stammdaten im Rechnungswesen (Report/Transaktionscode RSSCD100)" näher beschrieben.

Auch wenn Kostenstellen, als Orte der Kostenentstehung langfristig Bestand haben sollen und dabei die Organisation des Unternehmens (oder der Einrichtung) abbilden sollen, kann es doch manchmal sinnvoll sein, auch bestehende Objekte nicht ewig im System bleiben müssen. Gründe können hier eine Änderung des Organisationsaufbaus sein oder tatsächlich eine falsche Nummer bei der Anlage einer Kostenstelle :-)

Gerade im Rechnungswesen, insbesondere auch im Controlling, stellt sich oft die Frage, wann und durch wen und wann eine Änderung von Stammdaten erfolgt ist. Dieses kann auch aus Sicht der Revision relevant sein und hat manchmal auch andere Hintergründe.

Im Gespräch mit einen Kollegen hat sich herausgestellt, dass nicht nur in der Stammdatenpflege selbst die Änderungsbelege zum Feld ausgewertet werden können, sondern auch eine übergreifende Auswertung anhand der Objektklasse für alle Änderungsbelege im SAP System möglich ist.

Ausgangslage:
Für eine Auswertung der gesperrten Kostenstellen kann die Transaktion KS13 genutzt werden.

Allerdings hat diese Auswertung unter:

• Rechnungswesen
• Controlling
• Kostenstellenrechnung
• Infosystem
• Berichte zur Kostenstellenrechnung
• Stammdatenverzeichnis
• Kostenstellen: Stammdatenbericht (Transaktion KS13)

den Nachteil, dass hier zwar für alle Kostenstellen die (gesetzten) Kennzeichen für

1. Primärkosten (Ist)
2. Primärkosten (Plan)
3. Sekundärkosten (Ist)
4. Sekundärkosten (Plan)
5. Erlöse (Ist)
6. Erlöse (Plan)
7. Obligofortschreibung

zwar mit X markiert sind, wenn diese gesetzt sind aber nicht ersichtlich ist, wann diese Sperre gesetzt worden ist. Um dieses Datum zu erfahren, muss in der Stammdatenpflege zur Kostenstelle (KS02, KS03) über

UMFELD->ÄNDERUNGSBELEGE->ZUM FELD

zu jeden einzelnen Feld eine Auswertung der Änderungen durchgeführt werden um zu erfahren, wann hier eine Änderung erfolgte.

Leider ist es hier nicht so einfach eine Änderungsauswertung wie "Änderungsbelege zu Systemstatus (JEST) bei Innenaufträgen per Query auswerten" bei den CO Innenaufträgen durchzuführen. Auch bei Stammdatengruppen war dieses mit einer im Artikel "Änderungsbelege für Stammdatengruppen im Customizing oder letzte Änderung über Query bspw. für Innenauftragsgruppen" beschriebenen Query möglich.
 

Tabellen CDHDR und CDPOS zur Änderungsprotokollierung

Eine Protokollierung der Stammdatenänderungen von Kostenstellen (aber auch von anderen Stammdatenobjekten erfolgt in den Tabellen

• CDHDR Änderungsbelegkopf
• CDPOS Änderungsbelegpositionen

Zweitere ist eine Clustertabelle, die leider nicht direkt in einer Query verwendet werden kann, da es sich um eine Struktur handelt. Die Einstellung zur Protokollierung kann über die Transaktion AUT03 erfolgen. Eine Änderung kann hier aber aus Revisionsgründen problematisch sein, daher möchte ich an dieser Stelle nicht weiter darauf eingehen, sondern auf die Auswertung der Tabelle CDHDR eingehen.

Über die Felder Objektklasse und ObjectID könnten hier das Objekt KOSTL für Kostenstelle und Objektwert bestehend aus der Objektbezeichnung (Kostenrechnungskreis und die Kostenstelle inkl. führenden 0) die Änderungsbelege mühsam ausgewertet werden.

Hier sind dann Änderungsdatum UDATE, Uhrzeit der Änderung UTIME und Transaktion mit der die Änderung durchgeführt wurde TCODE ersichtlich. Die Änderungen (insbesondere wleche Felder geändert worden sind) sind nun aber in der Tabelle CDPOS zu finden.

Änderungsbelege für Objektklasse in SAP anzeigen

Um diese auszuwerten, gibt es im SAP System einen ABAP Report RSSCD100 der auch über den Transaktionscode (Parametertransaktion) RSSCD100 Änderungsbelege anzeigen gestartet werden kann.

Über die Objektklasse kann nun für unterschiedliche Object-id (oder alternativ alle eine Liste aller Änderungen ab Datum bis Datum (inklusive Uhrzeit) und auch mit einer Selektion des letzten Änderer ausgeführt werden.

Relevant für unsere Auswertung ist das Feld Objektklasse sowie der Änderungszeitraum:

• ab Datum
• ab Uhrzeit
• bis Datum
• bis Uhrzeit
• ggf. noch letzter Änderer.

Die Transaktion RSSCD100  bietet noch eine Menge anderer Optionen an.
Unter anderen die Option "Lesen aus dem Archivinfosystem, Lesen aus der Datenbank, Plus(+) oder auch Stern (*) kein WIldcard. Sind diese Optionen nicht gewünscht kann acuh der ABAP Report RSSCD200  verwendet werden. Dieser ist keinen Transaktionscode zugeordnet und hat dafür weniger Optionen beim Aufruf. Ich würde daher die Transaktion RSSCD100 und nicht SA38 für den Report RSSCD200 verwenden.
 

Änderungsbelege für Kostenstelle, Materialstamm, Kreditor und andere Objekte anzeigen (Objektklassen)

Als Objektklasse können im Rechnungswesen zum Beispiel folgende Werte genutzt werden:

Gemeinkostencontrolling CO-OM / Profitcenterrechnung EC-PCA

• KOSTL  Kostenstelle
• PRCTR  Profitcenter
• KSTAR  Kostenart
• RKAUFTRAG  Innenauftrag

Public Secter Management

• FMFCTR  Finanzstelle
• FMFONDS  Fonds
• FMCI  Finanzposition

Finanzbuchhaltung

• KRED  Kreditorenstammdaten
• DEBI  Debitorenstammdaten
• ANLA Anlagenstammdaten (FI-AA)

Logisitk / Einkauf

• MATERIAL  Materialstamm
• EINKBELEG Einkaufsbeleg
• BANF Bestellanforderung
• FAKTBELEGE  Faktura/Rechnung
• VERKBELEG  Verkaufsbeleg/Angebot/Auftrag

und andere...

Auswertung Änderungsbelege der Objektklasse ... als ALV

Im Ergebnis erhalten wir eine ALV Liste mit u.a. folgenden Feldern:

• Objektwert
  Bei der Auswertung von KOSTL (Kostenstellen) ist dieses die Objektnummer der Kostenstelle bestehend aus Kostenrechnungskreis sowie die Kostenstellennummer mit führenden 0
• Belegnummer
  Der Änderungsbeleg
• Benutzer
  SAP User der die Änderung durchgeführt hat (letzter Änderer)
• Vorname, Nachname, Abteilung  zum Benutzer
• Datum, Uhrzeit der Änderung
• TCode
  Transaktionscode mit dem die Ändeurng durchgeführt wurde (bspw. KS02)
• Tabelle und Kurzbeschreibung der Tabelle
  Zum Beispiel CSKSB "Struktur Kostenstellenstamm für Änderungsbelege"
• Tabellenschlüssel
  Technischer Änderungsschlüssel?
• Feldname
  Welches Feld wurde im Stamm geändert, bspw. ABTEI für Abteilung oder die Sperrkenzeichen
• Kurztext, kurz, mittel, lang
  des Feldes das geändert wurde
• alter Wert
• neuer Wert
• Änd.kz.
  Dieses Änderungskennzeichen beschreibt die Art der Änderung
  • U - Update
  • I - Insert
  • E - Delete (singele field documentation)
  • D -  Delete
  • J - Insert (single field documentation)
• meitens dürfte dieses U für Update sein

Damit ist es recht umfangreich möglich entsprechende Auswertungen über die Sperrkenzeichen auszuführen. Hierzu muss nur in der ALV Liste zum Objekt KOSTL die entsprechenden Feldnamen gefiltert werden. In der Regel dürfte hier aber das Feld BKZKP "Primärkosten Ist" ausreichend sein.

Fazit

Dieser Report ist sehr umfangreich dürfte aber obige Anforderung tatsächlich efüllen und zeigt gleichzeitig eine Möglichkeit um Massenänderungen nachzuvollziehen zu können. Durch den eigenen Transaktionscode ist es sogar möglich den Report berechtigungsseitig direkt ohne Zuordnung der SA38 zuzuweisen. :-).
 

Sobald der Wechsel nach SAP S/4HANA konkreter wird stellt sich auch die Frage, wie die Daten aus vorherigen Systemen (SAP ERP oder auch andere Anwendungen) in das neue S/4 HANA System übertragen werden soll.

Das Thema Datenmigration, um das es letzendlich geht, findet aber auch in anderen Bereichen Anwendung und ist gerade bei bei Stammdaten ein Thema, dass sich auch im Tagesgeschäft bewährt hat. Neben vielen anderen Themen wie das Zusammenwachsen von Finanzbuchhaltung und Controlling ist auch die Datenmigration ein Thema, dass möglichst frühzeitg angegangen werden sollte.

Hier habe ich im April 2020 auch mein erstes S/4HANA Buchprojekt bei Espresso Tutorials abgeschlossen.
 
Ergänzend zum Video (siehe Artikel "Sagen Sie mal Herr Unkelbach, ... Was ist das Migrationscockpit? (Datenmigration nach S/4 mit LTMC LTMOM)") mag ich gerne auf einige Fragen eingehen.
 

Funktioniert die Massenstammdatenpflege unter S/4HANA noch?

Unter SAP ERP nutzen wir im Hochschulbereich sowohl eCATT als auch LSMW zur Anlage von Stammdaten. Das Vorgehen habe ich im Artikel "Massenstammdatenpflege mit LSMW oder SECATT dank Transaktionsaufzeichnung - Handbuch erweiterte computergestützte Test-Tool (eCATT) und LSMW" näher beschrieben.

Im Rahmen der "FICO Forum Infotage 2017" präsentierte Jörg Siebert am Rande seines Vortrags "Geschäftsprozesse in der S/4 HANA Anlagenbuchhaltung" auch ie Nachfolge der LSMW das SAP S/4 HANA Migrationscockpit. Diess ist eine verbesserte Nachfolge der LSMW und auch seitens der SAP wird im SAP Hinweis 2287723 darauf hingewiesen, dass die Funktion der LSMW zwar in der On-Premise-Edition noch verfügbar sei, aber nicht weiter unterstützt wird. Unter Umständen kann es hier sogar zu falschen Migrationsschnittstellen kommen, so dass neue Entwicklungen hier gar nicht berücksichtigt werden.

Da das Migrationscockpit aber auch noch weitere Verbesserungen gegenüber der LSMW hat, war dies ein guter Anlass für mich, sich intensiver mit Migrationscockpit (LTMC) und Migrationsobjektmodellierer (LTMOM) sich auseinander zu setzen.

Was macht das Migrationscockpit?

Das Migrationscockpit (LTMC) ist eine Oberfläche mit der die gesamte Stammdatenpflege autmatisiert werden kann. Es ist ein Tool zur Datenmigration und Sie legen eines der neu eingeführten Migrationsprojekte im Cockpit an.

Was ist ein Migrationsprojekt

Die Verwaltung von Projekt, Teilprojekt und Objekt ist Ihnen vielleicht schon durch die LSMW bekannt, mit LTMC bekommen die Migrationsprojekte jedoch eine neue Bedeutung und umfassendere Funktion.

Innerhalb eines Migrationsprojektes wähle ich aus, welche Stammdatenbjekte ich in S/4HANA anlegen möchte. Hier hat die SAP eine weitere neue Vokabel eingeführt, das Migrationsobjekt.

Die Migrationsobjekte sind Vorlagen für die Migration ihrer (Stamm)Daten. Das Migrationsprojekt fasst dann alle Migrationsobjekte zusammen.

Wie pflege ich meine Daten zur erfolgreichen Datenmigration?

Die Vorlagen (Templates) erhalten Sie als formatierte Exceltabelle (XML Dateien) in der Sie alle zugehörigen Stammdaten eintragen können. Diese Datei laden Sie im Cockpit hoch um sie von dort aus weiter zu verarbeiten. Dabei haben Sie hier gegenüber der CSV von LSMW oder eCATT nicht mehr das Problem, dass Sie auf die Formatierung von Datumswerten oder anderen Feldern achten müssen sondern diese vorgegeben bekommen.

Beim Hochladen der Daten kommt ein weiterer Vorteil des neuen Tools zur Geltung.

Im Migrationscockpit erfolgt die technische Überprüfung der Daten, die nicht nur auf vorgegebene Regeln beruht sondern durch individuellen Anforderungen ergänzt werden kann.

Darüberhinaus lässt sich die Datenübertragung auch simulieren, so dass Sie eventuell notwendige Anpassungen (Customizing, Stammdaten) noch vor der endgültigen Datenübernahme in ihr Zielsystem vornehmen können. Wenn ich mit den Ergebnis der Simulation zufrieden bin kann ich mit einen einzelnen Klick die Daten endgültig in mein System übernehmen.

Wo sehe ich weitere Vorteile?

Neben der Simulation und der Technik der Datenübertragung ssehe ich einen enormen Vorteil bei der Zusammenarbeit mit dem Fachbereich. Durch die vorgegebene Formatierung der Excel-Vorlage ist es für die fachlich verantwortliche Personen einfacher das Template auszufüllen. Dieses reduziert nicht nur Ihren Aufwand sondern erleichtert mir auch später die Verwendung dieser Daten.

Ebenfalls beeindruckt hat mich der Umgang mit fehlerhaften Datensätzen. Früher musste ich hier entweder im Protokoll der Dateneinspielung nachsehen, an welcher Stelle das Einspielen nicht geklappt hat oder alternativ immer wieder enreut die CSV Datei anpassen bis alle Dateien eingespielt sind. Hier ist das Konzept der Dettadatei großartig, da hier eine Vorlage angeleg wird mit allen Datensätzen die nciht eingespielt worden sind. :-) Dieses erleichtert auch nach der Simulation noch unheimlich die Datenmigration, wenn wir diese regelmäßig einsetzen.

Gibt es Vorlagen für all meine Stammdatenobjekte?

Seitens der SAP werden schon viele Migrationsobjekte zur Verfügung gestellt. Mit diesesn können auch einige Standardobjekte angelegt werden. Dazu zählen neben einfachen Migrationsobjekten wie Kostenstellen, Profitcenter unter anderen auch komplexere Objekte wie Anlagenstammdaten mit Bewegungsdaten,  die Geschäftspartner als Nachfolge der Kreditoren und Debitoren oder auch offene Postenlisten.

Sollten die Möglichkeiten nicht ausreichen, gibt es in der OnPremise Version von S/4HANA mit den Migrationsobjektmodellierer ein Werkzeug um eigene Migrationsobjekte anzulegen oder vorhandene an ihre Bedürfnisse anzupassen.

Woher bekomme ich weitere Informationen zur Datenmigration mit LTMC und LTMOM?

Hier kann ich mein erstes S/4HANA Buchprojekt empfehlen :-).

Eine ausführliche Beschreibung ist unter Buchempfehlungen unter  SAP S/4HANA Migration Cockpit - Datenmigration mit LTMC und LTMOM (SAP S/4HANA, BC, Datenmigration) zu finden.

  (14. April 2020) Paperback ISBN: 9783960120179

Für 29,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Oder bei Amazon **

Ich freue mich schon sehr über die ersten Rückmeldungen zum Buch und auch wenn diese geteilt werden :-).

Gerne kann hier auch auf meine Socialmedia Kanäle

Facebook oder auch Twitter

verwiesen werden.

Ich freue mich, wenn meine Inhalte geteilt werden 🥰 

Sehr gerne kann dies über meinen "Beitrag auf Facebook" erfolgen 👍.

Schon vorab vielen Dank dafür.

Weitere Themen, neben LTMC und LTMOM, im Buch sind auch grundsätzliche Überlegungen zur Datenmigration sowie eine Beschreibung der bisherigen Datenmigrationstools unter SAP ERP wie eCATT und LSMW, so dass dieses Buch nicht nur zur Vorbereitung auf einen anstehenden Wechsel nach S/4HANA sondern auch für die alte ERP Welt einen Nutzen hatt :-).

An dieser Stelle mag ich mich auch bei allen bedanken die zum Gelingen dieses Buch beigetragen haben und auch schon im Vorwort erwähnt worden sind.  Besonderen Dank gilt hier aber auch meiner Frau Claudia Unkelbach, die nicht nur gute Ideen zum Buch beigetragen hat (sowie die Videos zum Buch ermöglicht hat) sondern auch selbst immer wieder unter Beweis stellt, dass viel mehr möglich ist, wenn man sich dem Unbekannten gegenüberstellt und hier auch Neues lernt und die damit verbundenen Herausforderungen meistert. :-)

Neben der Kostenartenrechnung im SAP Modul CO-OM (Gemeinkostencontrolling) können auch Sachkonten im Controlling für das Berichtswesen relevant werden. So besteht die Möglichkeit innerhalb der Profit-Center-Rechnung (EC-PCA)  eigene Kontengruppen anzulegen in denen sowohl Sachkonten als auch Kostenarten hinterlegt werden können und entsprechend in der Profit-Center-Rechnung ausgewertet werden können.
Dieses ist im SAP Menü unter

• Controlling
• Profit-Center-Rechnung
• Stammdaten
• Kontengruppen

durch die Transaktionen KDH1 (Anlegen), KDH2 (Ändern) und natürich auch KDH3 (Anzeigen)  möglich.

Während jedoch die Kostenartenrechnung unter:

• Controlling
• Kostenartenrechnung
• Infosystem
• Berichte zur Kosten-/Erlösartenrechnung
• Stammdatenverzeichnisse

durch die Transaktion KA23 "Kostenarten: Stammdatenbericht" die Möglichkeit anbietet alle einer Kostenartengruppe zugeordnete Kostenarten als ALV Liste zu erhalten fehlt diese Option im Infosystem der Profit-Center-Rechnung.

Hilfsweise können natürlich Sets wie im Artikel "Auflösen von Stammdatengruppen nach Einzelwerten - Einzelwerte zu Sets" beschrieben ausgewertet werden, jedoch macht dieses dann bei Intervallen Probleme und man müsste für einen Kontenplan wie im Artikel "Query Kontenplan für Module CO, FI und PSM" die Zuordnung von Kostenart und Sachkonto zur Stammdatengruppe in Excel wie unter "Prüfung inwieweit ein Wert, bspw. eine Kostenstelle, innerhalb eines Intrevalls (Gruppe) liegt in Excel" beschrieben durch Veweisfunktionen und Bedingungen zuordnen.

Auswertung von Stammdatengruppen Sachkonten (SE16H über SKAT)

Sollen nun aber nun alle Sachkonten die einer  (oder untergeordneten) Kontengruppe zugeordnet sind ausgewertet werden bietet sich hier die Transaktion SE16H zum Auswerten von SETS an.

Mit der SE16H "Allgemeine Tabellenanzeige" kann die Tabelle SKAT "Sachkontenstamm (Kontenplan: Bezeichnung)" ausgwertet werden und hier als Kontenplan (bspw. IKR) sowie Sprache DE nur relevante Sachkonten ausgwertet werden. Im Tabellenfeld Sachkonto (Tabelle SKAT Feld SAKNR) kann nun in der Transaktion SE16H durch die Spalte Gruppe auf Gruppen zu diesen Feld zugegriffen werden.

Nun kann auf ein Set mit Bezug auf den Feldnamen SAKNR zugegriffen werden. Sinnvoll ist es hier nach Bestätigung auf WEITER bei Auswahl des SETNAME * zum Bezugsfeld Feldname SAKNR  (grüner Hacken, ENTER) die gelisteten Sets über Einschränkungen (Dreieck oberhalb der Trefferliste) über die Setklasse "Kontnegruppe" einzuschränken um hier die entsprechende Stammdatengruppe auszuwählen (als Beispiel kann hier IKR-5 oder HFS relevant sein).

Im Ergebnis erhalte ich nun alle dieser Kontengruppe oder untergeordneten Kontengruppen zugeordnete Sachkonten.

Dabei ist es, gerade bei mehrsprachigen Systemen sinnvoll vorab in der Selektion auch Kontenplan (IKR oder lokale Kontenplan) sowie die Sprache DE ausgewählt zu haben, da andernfalls die Sachkonten gerne auch mehrfach ausgegegeben werden.

Auswertung von Kostenarten inklusive kundeneigener Zusatzfelder (SE16H über CSKB)

Mit der Nutzung von kundeneigener Zusatzfelder für die Kostenarten (siehe "Stammdatenerweiterung von CO-Objekten am Beispiel ergänzende Kostenstelle beim Innenauftrag" Userexit COOMKA01) und dieTabelle CSKB in der die Zusatzfelder gespeichert sind.

In der Transaktion SE16H kann zum Tabellenfeld "Kostenart" (KSTAR) der Tabelle "Kostenarten (Kostenrechnungskreisabhängige Daten)" (CSKB) ausgewertet werden und in der Spalte Gruppe nun ebenfalls das Set Kontenrguppe gewählt werden um alle in der Kontengruppe IKR-5 oder HFS-RELEVANT zugeordneten Kostenarten auszuwerten.

Hierzu muss ebenfalls due Setklasse auf "Kontengruppe" eingeschränkt werden. Dieses ist nach Auswahl Sets und Bestätigen von Setnmae * über den Feldnamen KSTAR über die Schaltfläche (Dreieck) Einschränkung über die Setklasse "Kontengruppe" möglich.

Hier ist es dann auch möglich wie in der KA23 die gepflegten Zusatzfelder mit auszugeben. Wenn es um eine reine Kostenartengruppe gehen würde (und nicht Kontengruppe) ist dieses auch im Artikel "Auswertung per CMOD eingeführter kundeneigener Felder Kostenart, Kostenstelle und Innenauftrag per Stammdatenverzeichnis und SAP Query" näher erläutert. Vergleichbar zur KA23 werden hier auch die untergeordneten Gruppen.

Fazit

Dadurch, dass die Auswertung der SETs/Gruppen nicht im Zusammenhang mit der Anwendung der Tabelle stehen könnnen hier unterschiedliche Stammdatengruppen zu den einzelnen Feldern ausgewählt werden. Neben Kontengruppen und Kostenartengruppen für die Stammdaten der "Buchungskonten" nutze ich diese Transaktion zum Beispiel auch über die verantwortliche Kostenstelle der CO Innenaufträge (Tabelle AUFK Feld KOSTV) um alle Innenaufträge der Kostenstellengruppe FB01 angezeigt zu bekommen. Damit erhalte ich alle Innenfträge die seitens der Kostenstelle hier zugeordnet sind und muss mir keinen Gedanken um die Kostenstellennummern selbst machen.

Aber auch abseits der schnellen Auswertung von Tabellen und Bezug zu den Gruppen bietet die Transaktion noch einen Mehrwert den Isa von thinkdoforward.com im Artikel "Entdecke die integrierte Pivot-Tabellen-Funktionen in SAP" beschrieben hat.


Im Buch »Berichtswesen im SAP®-Controlling« bin ich ausführlich auch auf die Bedeutung von Stammdaten eingegangen für den Aufbau von Informationen eingegangen.
  Vielleicht finden sich hier ja auch noch weitere Anregungen für den Aufbau eines Berichtswesen mit SAP nicht nur für CO im Buch.
 
Zumindest für Keyuser/Poweruser kann diese Transaktion ein nützliches Werkzeug im Berichtswesen sein um hier Daten direkt auswerten zu können. Teilweise sind hier auch Funktionen möglich (insbesondere der Zugriff auf die SET und die entsprechende Auswertung und Ausgabe der Tabellen) die mit SAP Query etwas mehr Aufwand verursachen.

Ausgangslage:
Innerhalb des Gemeinkostencontrolling (CO-OM) sind Stammdaten um kundeneigene Zusatzfelder erweitert worden um hier über die verfügbaren Stammdatenfelder hinaus weitergehende Informationen festzuhalten.

Im Artikel "Stammdatenerweiterung von CO-Objekten am Beispiel ergänzende Kostenstelle beim Innenauftrag" bin ich da schon einmal darauf eingegangen.

Im Rahmen des Hochschulberichtswesen war es hier besonders interessant die Stammdaten Kostenarten, Kostenstellen und Innenaufträge um weitere Stammdatenfelder zum Beispiel im Rahmen der Hochschulfinanzstatistik zu erweitern. Hier werden Kostenarten sogenannte Systemfinanzierungscodes und Kostenstellen sowie Innenaufträge Fächergruppen zugeordnet (was auch per SET/Gruppe möglich wäre). Auf die Hintergründe dazu bin ich im Artikel "Pivottabellen ab Excel 2010 dynamischer filtern mit Datenschnitten am Beispiel Hochschulfinanzstatistik" näher eingegangen.

Gerade was die Hochschulen in Hessen anbelangt schätze ich hier schon immer einen technischen Austausch so dass auch ein kleiner Ausflug nach Frankfurt (und für mich aus Gründen im Anschluss nach Darmstadt) dazu führen kann, dass hier bestimmte Artikel ein klein wenig länger liegen bleiben.. :-)



Aber der Ausflug nach Frankfurt hat sich tatsächlich gelohnt, führte uns doch eine Stadtführung in die "neue Altstadt" von Frankfurt, um zwischen Dom und Römer verwinkelte Gassen und Rekunstruktionen sowie 20 Neubauten historischer Gebäude im Rahmen einer Stadtführung zu entdecken.

Für alle abseits der Teilnehmenden dürfte aber das Thema Zusatzfelder wesentlich interessanter sein, so dass ich darauf direkt eingehen möchte.
 

Userexit für kundeneigene Zusatzfelder im Stammsatz

Technisch erfolgt die Umsetzung über einen Customer-Exit der über CMOD angelegt wird.

Im Wesentlichen ist es möglich über sogenannte Userexits Zusatzfelder zu Stammdaten zu erstellen. Dieses ist über die Transaktion CMOD möglich und zum Beispiel für

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

möglich.

Als weitere Objekte mit der Möglichkeit kundeneigene Zusatzfelder anzulegen wären unter anderen noch:

• Leistungsarten:
  https://www.consolut.com/s/sap-ides-zugriff/d/e/doc/P-COOMLA01/
• oder auch aus der Prozesskostenrechnung für Geschäftsprozesse:
  https://www.consolut.com/s/sap-ides-zugriff/d/e/doc/P-COOMBP01/

Eine Übersicht aller Userexits ist auch auf der Seite easymarketplace.de möglich.
Im Berater-Wiki ist die Nutzung von CMOD anhand eines Beispiels im Eintrag "Customer-Exits" erläutert.

Eine Auswertung dieser gepflegten Felder ist sowohl in den Stammdatenberichten als auch über die Stammdatentabellen durch sogenannte CI (Customer_Includes) innerhalb der Tabellen möglich. Für die von uns gepflegten Daten ist dieses im Artikel "Auswertung per CMOD eingeführter kundeneigener Felder Kostenart, Kostenstelle und Innenauftrag per Stammdatenverzeichnis und SAP Query" beschrieben.

Zusammengefasst werden hier die Stammdatentabellen um ein CI (Customer Include) erweitert, so dass hier die weiteren Datenfelder in der Tabelle ebenfalls mit eingebunden werden.

Pflege der kundeneigener Zusatzfelder per Massenpflege

Abseits der Auswertung all jener Zusatzfelder stellt sich aber auch die Frage, wie die Daten künftig gepflegt werden sollen.

Grundsätzlich bieten sich unterschiedliche Methoden an um diese Felder dann mit Daten zu versorgen. Gerade wenn nachträglich eine Menge an Stammdaten um diese Informationen beeichert werden sollen ist eine Massenpflege sicherlich das passende Mittel der Wahl.
 

eCATT für Zusatzfelder im Gemeinkostencontrolling (zum Beispiel Kostenstelle)

Unterschiedliche Methoden sind im Artikel "Massenstammdatenpflege mit LSMW oder SECATT dank Transaktionsaufzeichnung - Handbuch erweiterte computergestützte Test-Tool (eCATT) und LSMW" beschrieben, wobei wir uns hier für einen eCATT entschieden haben.

Beim Einspielen der CSV Datei gab es jedoch eine Fehlermeldung obgleich vorher die Transaktion KS02 zur Änderung von Kostenstellen ordentlich aufgezeichnet worden ist.

Nachdem die Transaktion einzeln aufgerufen wurde, war die Ursache schnell gefunden. Für die Kostenstellen sind teilweise unterschiedliche Betrachtungszeiträume berücksichtigt.

Unter BEARBEITEN > BETRACHT.ZEITRAUM...  können für einzelne Zeitabschnitte Änderungen festgehalten sein.

Hier hatte mir ein Kollege die Empfehlung gegeben zwei Testfälle aufzuzeichnen:

1. ein eCATT für eine Kostenstelle ohne unterschiedliche Betrachtungszeiträume
2. ein eCATT für Kostenstellen die mehr als einen Betrachtungszeitraum haben.

Um eine Pointe vorwegzunehmen wäre es noch möglich mehrere eCATT aufzuzeichen mit 2, 3, 4 ... und natürlich weitere, je nachdem wieviele Betrachtungszeiträume so allgemein  zur Verfügung stehen, aufzuzeichnen.

Nachdem wir nun den zweiten eCATT abgespielt hatten, war tatsächlich die Änderung, Hinterlegung des SYF Code an der Kostenstelle in jeden Betrachtungszeitraum festgehalten.

Zeitabhängige Felder für ... festlegen

Tatsächlcih liegt dieses daran, dass die angelegten Kundenfelder keine Zeitabhängigkeit festgelegt bekommen.

Im Customizing (Transaktion SPRO) sind für die obigen Userexits für die Kundenfelder an folgender Stelle festzulegen.

Auf die einzelnen Felder gehe ich in den folgendne Abschnitten ein.
 

Zeitabhängigkeit kundeneigene Felder für Kostenstelle Userexit COOMKS01  - Transaktion OKEG

Ein Klassiker im Gemeinkostencontrolling ist die Kostenstelle unter der ebenfalls kundeneigene Felder gepflegt werden. Für die Hochschulfinanzstatistik würde es sich hier anbieten die Fächergruppe oder auch Lehr und Forschungsbereich zu hinterlegen.

Unter

• Controlling
• Kostenstellenrechnung
• Stammdaten
• Kostenstellen
• Zeitabhängige Felder für Kostenstellen festlegen

oder alternativ per Transaktion OKEG kann für die per Userexit COOMKS01 angelegten Felder markiert werden, so dass diese zeitabhängig eingestellt werden.

Die Zeitabhängigkeit wird hier tatsächlich durch die SAP festgelegt und unterschieden zwischen Tag, Periode, GJahr oder keine unterschieden. Durch die Checkbox wird die entsprechende Zeitabhängigkeit aktiviert (für die Kundenfelder ist dieses tatsächlich eine tagesabhägige Zeitabhängigkeit.

Da ich ja auch die obigen Userexit erwähnt habe, erwähne ich auch gleich noch für die anderen Felder die Customizingpfade:

Zeitabhängigkeit Zusatzfelder für Kostenart Userexit COOMKA01 - Transaktion OKEK

Für die Kostenarten könnte es sich anbieten hier Systemfinanzierungscodes zu hinterlegen. Diese ordnen Erträge, Aufwendungen oder Investitionsausgaben gruppiert werden. Hier bietet es sich an die Kostenart um diese Funktion zu ergänzen gerade, da nicht nur über Kostenartengruppen sondern vielleicht auch in Listen entsprechend selektiert werden können.

Für Kostenarten (Userexit COOMKA01) ist dieses unter

• Controlling
• Kostenartenrechnung
• Stammdaten
• Kostenarten
• Zeitabhängige Felder für Kostenarten festlegen

bzw. Transaktion OKEK.

Zeitabhängige Felder für Leistungsart Userexit COOMLA01 - Transaktion OKEI

Auch für Leistungsarten könenn Zusatzfelder per Userexit COOMLA01 einer Zeitabhängigkeit festgelegt werden.

• Controlling
• Kostenstellenrechnung
• Stammdaten
• Leistungsarten
• Zeitabhängige Felder für Leistunsgarten festlegen

oder eben direkt per Transaktionscode OKEI.

Zeitabhängige Felder für Geschäftsprozesse Userexit COOMBP01 - Transaktion OKEZ

In der Prozesskostenrechnung findet sich die Einstellung unter

• Controlling
• Prozeßkostenrechnung
• Stammdaten
• Geschäftsprozesse
• Zeitabhängieg Felder für Geschäftsprozesse festlegen

und kann ebenfalls über einen Transaktionscode in diesen Fall OKEZ eingestellt werden.

Fazit - sollten die Zusatzfelder zeitabhängig oder zeitlos sein

In unseren Fall dürfte es aber tatäschlich am interessantesten gewesen sein, hier keine Zeitabhängigkeit festgelegt zu haben, so dass die Erfassung unproblematisch war.

Gerade bei einer jährlichen Statistik in der keine Vorjahresvergleiche der Stammdaten erfolgt, ist es hier sinnvoll eine direkte Zuordnung über die Ewigkeit zu haben, als noch an die einzelnen Betrachtungszeiträume zu denken.

Interessant ist übrigens, dass in den Stammdatentabellen für die CO Objekte tatsächlich die Betrachtungszeiträume mehrfach gefüllt sind, aber hier für das Zusatzfeld stets der gleiche EIntrag automatisch zu finden ist, so dass bei Bedarf tatsächlich die Zeitabhängigkeit auch im Nachhinein aktiviert werden kann.

Besonders interessant war es hier tatsächlcih aus der Datenbankebene (die Stammdatentabelle war für jeden einzelnen Betrachtungszeitraum mit einen Wert versehen), über einen fachlichen Austausch bishin zur Möglichkeit der Anpassung im Rahmen des Customizing einzugehen.

Die Idee tatsächlich nur zwei eCATT aufzuzeichnen, ist da tatsächlich der einfache Weg, auch wenn über die Massenpflege bspw. per MASS wohl ebenfalls Zusatzfelder als zu pflegende Stammdatenfelder angepasst werden können.

Die Bedeutung von Stammdaten oder auch Stammdatengruppen können bei der Konzeption de Berichtswesen tatsächlich eine wichtige Rolle spielen. Dieses ist auch der Grund, warum ich sowohl im Bereich Berichtswesen als auch beim Schnelleinstieg ins Controlling (siehe Punkt Publikationen) intensiver auf dieses Thema eingegangen bin.

Während die Geschäftsbereiche (oder Business Area) schon im klassischen Hauptbuch sowohl bei Innenaufträgen und Kostenstellen im SAP Modul CO-OM (Controlling - Gemeinkostencontrolling) hinterlegt werden kann wird der Profit-Center-Rechnung (EC-PCA) mit Einführung des neunen Hauptbuches ein neues Feld in den Stammdaten zugeordnet das sich auch auf das Berichtswesen auswirkt.  Es handelt sich um das Stammdatum Segment das insbesondere für die Segmentberichtserstattung genutzt werden soll.

Gesetzliche Grundlagen (IFRS, HGB, US GAAP)

Gemäß der gesetzlichen Anforderung im § 297 Absatz 1 Satz 2 HGB kann der Konzernabschluss um eine Segmentberichtserstattung erweitert werden. Nach den International Financial Reporting Standards (IFRS)  ist eine Segmentberichtserstattung für bestimmte Unternehmensformen (kapitalmarktorientierte Unternehmen) nach IFRS 8 verpflichtend für andere ist diese freiwilliger Bestandteil des Konzernabschlusses. Vergleichbare Regelungen finden sich schon länger innerhalb der United States Generally Accepted Accounting Principles (US-GAAP) als US-amerikanischen Bilanzierungsvorschriften.

Durch diese gesetzlichen Änderungen ist es auch nicht weiter verwunderlich, dass die Profit-Center-Rechnung nicht mehr im Controlling sondern auch im Menübaum innerhalb der Finanzbuchhaltung zu finden, da hier die Segmentberichtserstattung erfolgen soll.

Wofür wird die Segmentberichtesrstattung verwendet (Bibi Bilanzierung)

Unter #WirLiebenBilanzierung erläutert die Professur für Financial Accounting (Prof. Dr. Corinna Ewelt-Knauer) im Fachbereich Wirtschaftswissenschaften der Justus-Liebig-Universität Gießen unter Bibi Bilanzierung - Das innovative und interaktive Buch zur Fallstudiengeschichte diverses Wissen rund um die BWL  insbesondere Bilanzierung als Grundlage für Studium & Wissenschaftliches Arbeiten.

Dabei wurde auch unter Accounting on Point: Segmentberichterstattung die Frage beantwortet "Was steckt hinter der Segmentberichterstattung?". Da ich vom Format sehr begeistert bin und die dargestellten Folien noch einmal die Bedeutung der Segmentberichterstattung für die einzelnen Geschäftsbereiche in den Geschäftsberichten besonders unter die Lupe nimmt, mag ich diese gerne hier zitieren. Vielen Dank an dieser Stelle auch für das Okay an das Team von Bibi Bilanzierung bzw. Prof. Dr. Corinna Ewelt-Knauer.

Was steckt hinter der Segmentberichterstattung?

"Der Segmentbericht bietet strukturierte Informationen über einzelne Teileinheiten bzw. Geschäftsaktivitäten eines Unternehmens (=Segmente), um die im Abschluss aggregiert dargestellte Lage besser interpretieren zu können."

Welche Funktionen kann die Segmentberichterstattung erfüllen?

Dabei kann die Segementberichterstattung für folgende Funktionen genutzt werden:

• Erweiterung des Jahresabschlusses
• Verbesserter Einblick in Vermögens-, Finanz- und Ertragslage
• Veröffentlichung finanzieller Informationen einzelner Teilbereiche
• Einsicht in die Unternehmensentwicklung für (Potenzielle) Investoren/andere Kapitalgeber
• Externe Adressaten können Chancen und Risiken einzelner Segmente bewerten
• management approach

Wer sich für Finanzbuchhaltung, Bilanzierung und natürlich auch Bilanzbuchhaltung interessiert (oder auch Wissen auffrischen mag) findet bei Bibi.Bilanzierung auch passende kurze und lehrreiche Unterlagen.

Ich kann dabei folgende Quellen empfehlen:

  Bibi Bilanzierung | Startseite Youtube Instagram
 

Business Area im klassischen Hauptbuch und Segmente in der Profit-Center-Rechnung im neuen Hauptbuch

Bisher war die Profit-Center-Rechnung ein Nebenbuch und ist nun inhaltlich ins Hauptbuch gewandert, was sich auch im Bereichtswesen auswirkt.

Schon mit der Einführung des neuen Hauptbuches zeigt sich, dass das interne und das externe Rechnungswesen immer mehr zusammen wächst, was gerade bei der Einführung von S/4HANA dann auch darin gipfelt, dass hier Sachkonto und Kostenart zusammengelegt werden, was aber in diesem Artikel nicht gesondert dargestellt werden soll.

Am Beispiel "Grundlagen Finanzbuchhaltung - Geschäftsbereiche als mögliche Lösung zur Abbildung eines Betrieb gewerblicher Art (BgA)" hatte ich schon beschrieben, wie im klassischen Hauptbuch eine Bilanz/GuV über in CO Objekte hinterlegte Geschäftsbereiche erstellt werden kann. Wie im verlinkten Artikel erwähnt kann dieses im Gegensatz zur Profit-Center-Rechnung und Segmentberichtserstattung für eine differenziertere Betrachtung von einzelnen Geschäftsbereichen herangezogen werden.

Sichtbar wird dieses dadurch, dass die Kostenstellen und Innenaufträge einzelnen Geschäftsbereichen abweichend zur Zuordnung zu den einzelnen Profit-Centern zugeordnet werden können.

Damit ist es zum Beispiel möglich einzelne Innenaufträge einen eigenen Geschäftsbereich zuzuordnen und gleichzeitig mit anderen Innenaufträgen einen bestimmten Profit-Center zuzuordnen.

Durch die Aktivierung des neuenn Hauptbuches werden die Stammdaten der Profit-Center um das Feld Segment erweitert. Somit werden durch die Zuordnung der CO-OM Objekte Kostenstelle und Innenauftrag zu einem Profit-Center die Segmente als 1:1 Zuordnung aus Profitcenter und Segment abgeleitet.

Es ist also entscheidend sich vorba Gedanken über etwaige Berichtspflichten zu machen und wie Geschäftsbereiche oder Segmente gestaltet werden sollen.

Anforderungen an Segmente

Ziel der Segmente ist eine gesetzliche Anforderung aus US-GAP und IFRS in der Unternehmen verpflichtet werden einzelne Geschäftssegmente öffentlich zu legen und damit Lagebericht und Jahresabschluss miteinander zu verknüpfen.

Im klassischen Hauptbuch konnten dazu bisher unter anderen Profit-Center-Gruppen oder die erwähnten Geschäftsbereiche in Kostenstelle und Innenauftrag verwendet werden.

Segmente können dafür in den Grunddaten der Profitcenter (Abschnitt Grunddaten im Register Grunddaten) oder auch als zeitabhängige Daten im Anlagenstammsatz hinterlegt werden.

Definition von Segmenten im Customizing

Ebenso wie Geschäftsbereiche sind die Segmente im Customizing (Transaktion SPRO) anzulegen. Die Anlage erfolgt unter:

• Unternehmensstruktur
• Definition
• Finanzwesen
• Segment definieren

Hier können Segmente für die Segmentberichtserstattung durch Angabe von Segment und Beschreibung angelegt werden. Werden später Profitcenter definiert besteht die Möglichkeit hier ein angelegtes Segment auszuwählen und dieses im Profit-Center zu hinterlegen.

Ferner ist das Szenario "FIN_SEGM" Segmentierung den führenden Ledger für das die Segmentberichtserstattung erfolgen soll zuzuordnen. Dieses ist im Customizing (Transaktion SPRO) unterhalb von

• Finanzwesen (neu)
• Grundeinstellungen Finanzwesen (neu)
• Bücher
• Ledger
• Szenarios und kundeneigene Felder Ledgern zuordnen

möglich, wodurch festgelegt wird, welche Felder eines Ledger bei der Durchbuchung aus anderen Anwendungskomponenten fortgeschrieben werden. Hierzu ist das entsprechende Ledger zu markieren (zum Beispiel OL für führendes Ledger) und in der Dialogstruktur der Punkt Szenarios auszuwählen. Über neue Einträge kann hier das Szenario für Hauptbuchhaltung im Beispiel FIN_SEGM für Segmentierung ergänzend zur FIN_PCA für die Profitcenter-Fortschreibung ausgewählt werden.

In der Stammdatenpflege zum Profit-Center (Transaktion KE51, KE52) kann das Segment dann entsprechend ausgewählt werden.
 

Ableitung von Segmenten durch Kundenerweiterung (BAdI)

Sofern das Segment nach anderen Kriterien abgeleitet werden soll ist hier auch die Nutzung des Business-Add-In (Badi) FAGL_DERIVE_SEGMENT möglich.

Diese Ableitung kann ebenfalls im Customizing unter:

• Finanzwesen (neu)
• Grundeinstellungen Fiannzwesen (neu)
• Werkzeuge
• Kundenerweiterungen
• Business-Add-Ins (BAdIs)
• Ableitung Segment
• Segment ableiten

Dieses wird in folgender Logik abgeleitet.

1. Wird bei einer Buchung kein Segment angegeben, ermittelt das System das Segment aus der hier definierten Substitution
2. Sofern aus der Substitution kein Segment ermittelt werden kann wird das Segment aus den Stammdaten des Profit-Center abgeleitet

Zuordnung von Segmenten in Profit-Center Stammdaten (Beispiel)

Die Zuordnung von Profit-Center zu Segmenten erfolgt in folgender Logik. Ein Segment kann mehreren Profit-Centern zugeordnet sein, aber jedes Profit-Center nur einen Segment.

Nehmen wir als Beispiel die Profit-Center des Verlag NewMedia (das ich als Beispiel im Buch  »Schnelleinstieg ins SAP® Controlling (CO)«  verwendet habe.

Hier könenn die einzelnen Sparten der Fachbücher des Verlages einen Segment Fachbücher zugeordnet werden:



Der Aufbau von Segmenten in Verbindung mit Profit-Centern sollte so gewählt werden, dass hier eine andere Information abgebildet wird. Durch die Integration der Profit-Center ins neue Hauptbuch sind hier auch weitere Auswertungsmöglichkeiten gegeben. Wie bereits erwähnt finden sich die Profit-Center im SAP Menü nun nicht nur im Controlling sondern auch in der Finanzbuchhaltung unter:

• Rechnungswesen
• Finanzwesen
• Hauptbuch
• Stammdaten
• Profitcenter

In der Tabelle FAGLFLEXT (Hauptbuch: Summen) ist das Feld Segment nun ebenfalls neben Profitcenter vorhanden.

Auswertung von Segmenten

Im Gegensatz zu Geschäftsbereichen muss für die Segmentberichtserstattung keine Geschäftsbereich-Bilanzen in den Einstellungen der globalen Daten zum Buchungskreis in den Verfahrensparaemetern aktiviert werden. Allerdings steht das Segment im Gegensatz zum Geschäftsbereich in der Transaktion S_ALR_87012284 nicht als Selektionskritierium unter Verkehrszahlenabgrenzung zur Verfügung.

Die Auswertung von Segmenten erfolgt nun aber nicht über die Bilanz/GuV unter:

• Rechnungswesen
• Finanzwesen
• Hauptbuch
• Infosystem
• Berichte zum Hauptbuch
• Bilanz/GuV/Cash Flow
• Allgemein
• Ist-/Ist Vergleiche
• Bilanz/Guv (Transaktionscode S_ALR_87012284)

sondern hat einen eigenen Menübaum unterhalb von

• Infosysteme
• Rechnungswesen
• Finanzwesen
• Hauptbuch
• Infosystem (neu)
• Berichte zur Segment-Berichtserstattung

Hier findet sich unter anderen der Bericht "Segment Plan/Ist/Abw.) Transaktion S_E38_98000092 unter den im Abschnitt Berichtsselektion auch auf die Bilanz/GuV Struktur zugegriffen werden kann.

Alternative / Vergleich Profit-Centergruppen zu Segmenten

Problematisch bei der Nutzung von Segmenten für Auswertungen ist jedoch, dass diese nicht flexibel auf organisatorische Änderungen reagieren können, da eine nachträgliche Änderung der Zuordnung zum Profit-Center nicht erfolgen kann. Daher kann die Verwendung von Profit-Center-Gruppen und Auswertung der Bilanz/GuV durch Kopie der Bilanz/GuV Struktur wie im Artikel "Bilanz- GuV- Struktur definieren oder nach CO-PCA kopieren" beschrieben durchaus hilfreich sein. Sollen darüber hinaus auch die Kostenstellen und Innenaufträge ausgewertet werden, ist ein Blick auf die Berichtsbibliothek ZPC (siehe Artikel "Erweiterung Bibliothek 8A2 Ausweis Kostenstelle und Innenauftrag bei Selektion Profit-Center in ReportWriter" nützlich sein.

Weitergehende Informationen

Ein Überblick über Segmente und Gegenüberstellung der neuen Profit-Center-Rechnung zur klassischen Profit-Center-Rechnung ist 2015 auf den FICO-Forum Infotagen vorgestellt worden.

FICO Forum Infotage 2015
Die Unterlagen der einzelnen Vorträge werden traditionell im Nachgang ebenfalls auf fico-forum.de veröffentlicht (siehe "Unterlagen der 4. FICO-Forum Infotage 9/10 November Köln").

Die beiden Vorträge können auch heute noch abgerufen werden:

Unterschiede klassische/neue Profitcenter Rechnung
Martin Munzel - Espresso Tutorials
http://fico-forum.de/ET/infotage_2015/PCA/

Segmentberichterstattung im SAP Hauptbuch
Jörg Siebert - Espresso Tutorials
http://fico-forum.de/ET/infotage_2015/JS_Segment/

Da mit der Einführung von S/4HANA neben der Unicode-Umstellung, im Bereich PSM die Umstellung von der klassischen Budgetierung hin zu BCS (siehe "PSM Haushaltsmanagement Budgetverwaltungssystem BCS oder klassische Budgetierung"), die Einführung von Business Partner (Nachfolge von Kreditor und Debitor) und auch die Aktivierung des neuen Hauptbuches ein wichtiges Thema ist, dürften auch dieses Jahr die FICO Forum Infotage für Kolleginnen und Kollegen interessant sein.

Dieses Jahr finden die Infotage vom Dienstag 19. bis Mittwoch 20. November in Köln statt und als Themen stehen unter anderen:

• Update zu S/4HANA Finance 1909
  von Janet Salmon, SAP Deutschland SE & Co.KG
• S/4HANA-Anlagenbuchhaltung
  von Jörg Sieber, Espresso Tutorials GmbH
• aber auch Geschäftspartner-Migration
  von Samuel Gonzalez, ConVista Consulting AG

auf der Agenda. Bis zum 31. Juli 2019 kann noch ein Frühbucherticket für 299 Euro erworben werden. Danach sind die Tickets ab 499 Euro zu haben.

Weiter Informationen zur Belegaufteilung nach Segment / Geschäftsbereich

Da das Thema durchaus noch mehr Aspekte hat, mag ich auf folgende Artikel verweisen:
 

• "Geschäftsbereiche als Belegaufteilungsmerkmal"
• "Segmente in der neuen Profitcenter-Rechnung als Belegaufteilungsmerkmal"
• "Betriebe gewerblicher Art (BgA) und Belegaufteilungsmerkmale Profitcenter, Segment, Funktionsbereich und Geschäftsbereich"

 

Gerade im Berichtswesen ist die Frage, was genau ausgewertet werden soll die Ausgangsfrage nach der dann unterschiedliche Berichtsanforderungen umgesetzt werden können. Eine der ersten Schritte ist die Definition von Gruppen um bestimmte Sachverhalte zusammenzufassen. Mit dieser Ausgangslage ist es auch nicht weiter verwunderlich, dass die Pflege von Sets und die Auswertung von Stammdatengruppen schon häufiger hier im Blog ein Thema war.

Als Beispiele verweise ich hier gerne auf die Artikel "Selektionsvariante KOK5 und Statusselektionsschemata zur Auswertung gesperrter Innenaufträge" zur Auswertung einer interaktiven Auftragsgruppe, "Änderungsbelege für Stammdatengruppen im Customizing oder letzte Änderung über Query bspw. für Innenauftragsgruppen" oder aber auch eine Query zur Auswertung von Stammdatengruppen wie im Artikel "Auflösen von Stammdatengruppen nach Einzelwerten - Einzelwerte zu Sets" beschrieben.

Ausgangslage Finanzbericht über Leistungsbereiche für einzelne CO-OM Innenaufträge
Im Rahmen eines Hochschulberichtswesen hat es durch den Wechsel einer Budgetierungssystematik eine Vielzahl neuer Innenaufträge gegeben, die nun in eine bestehende Innenauftragsgruppe eingepflegt werden sollen. Dabei sind die bestehenden aber auch die neuen Innenaufträge zu ergänzen und später auszuwerten.

Die "Projekte" werden sowohl als Fond im Modul PSM-FM als auch als Innenaufträge im Modul CO angelegt. Dabei sind die einzelnen Projekte hierarchisch aufgebaut, so dass die Einzelwerte auf unterster Ebene einer Gruppe eingepflegt werden.

Beispiel: "Für bestimmte Projektmittel werden diese im Hochschulbereich zwischen dezentrale Projekte die auf einzelne Lehreinheiten verteilt werden und Zentrale Projekte die über bestimmte Leistungsbereiche oder Ordnungskriterien zu berücksichtigen sind." Zur Verdeutlichung einmal ein kleiner Ausschnitt aus einer solchen Gruppe.

• Dezentral
  • Lehreinheit 01
  • Lehreinheit 02
  • Lehreinheit 03
  • Lehreinheit ...
• Zentral
  • Leistungsbereich 01
  • Leistungsbereich 02
  • Leistungsbereich 03
  • Leistungsbereich 04

In diesen Beispiel sind unterhalb der Lehreinheit 01 bis Lehreinheit ... keine weiteren Untergruppen vorhanden aber dort sollen die Innenaufträge eingepflegt werden.

Gleiches gilt für die Zuordnung der Innenaufträge zu den einzelnen Leistungsbereichen, die ebenfalls die unterste Gliederungsebene fürs Reporting umfasst. Wobei es hier natürlich nicht nur 4 Lehreinheiten oder 4 Leistungsbereiche gibt sondern wesentlich mehr... man könnte beinahe von einen ganzen Katalog an Kriterien oder gar Leistungsbereiche sprechen.

Sowohl in der Transaktion KOH2 (Auftragsgruppe ändern) als auch FM_SETS_FUND2 (Fondsgruppe ändern) können die obersten Knoten oder auch direkt die unterste Gruppenknoten gepflegt werden. Für die Anlage neuer Projekte ist bei der Fondsgruppe die Schaltfläche Fonds  und bei den Innenaufträgen die Schaltfläche Auftrag)  zu wählen.

Alternativ kann dieses auch im Menü statt der Schaltflächen über

• BEARBEITEN
• FONDS
  beziehungsweise.
  AUFTRAG
• FONDS EINFÜGEN
  oder
  AUFTRAG EINFÜGEN

möglich.

Danach sind 10 leere Felder eingefügt über die dann neue Einträge hinzugefügt werden können. Diese Funktion kann auch mehrfach erfolgen.

Aufsteigende oder Absteigende Sortierung der Einzelwerte

Praktischerweise muss sich um die Reihenfolge der Einträge keine Gedanken gemacht werden, wenn nach erfolgter Pflege auf die Gruppe geklickt wird und entweder über die rechte Maustaste die Funktion "Aufsteigend sortieren" oder ebenfalls über BEARBEITEN-> AUFTRAG oder FONDS-> die Funktion AUFSTEIGEND oder ABSTEIGEND SORTIEREN gewählt wird.

Massenpflege von Stammdatengruppen (SETS) am Beispiel der Innenauftragsgruppen im Modul CO-OM (Controlling Gemeinkostencontrolling)

Die neuen Projekte liegen inklusive einer Zuordnung der jeweiligen Stammdatengruppe als eine Arbeitsmappe in Excel (bzw. einer Tabellenkalkulation vor), so dass der naheliegende Gedanke war diese per Massenverarbeitung einzuspielen. Ebenso wie ein Kollege hatte ich hier den Gedanken die Pflege der Gruppen, wie im Artikel "Massenstammdatenpflege mit LSMW oder SECATT dank Transaktionsaufzeichnung - Handbuch erweiterte computergestützte Test-Tool (eCATT) und LSMW" beschrieben durch Aufzeichnen der Transaktion KOH2 und Upload einer CSV Datei einzuspielen.

Während ich keinen Erfolg beim eCATT hatte schien auch die LSMW hier nicht das geeigneteste Instrument zu sein. Das Hinzufügen neuer Einträge scheint hier nicht unterstützt zu werden. Ebenso gibt es auch keinen Massenupload aus der Zwischenablage in der Stammdatengruppenpflege.

Lösunngsansatz KOK4 Sammelbearbeitung von Innenaufträgen

Besonders schätzenswert ist an meinen Kollegen jedoch, dass er ebenfalls um die Ecke denken kann und so haben wir dann gemeinsam tatsächlich eine nciht ganz saubere aber dennoch funktionierende Lösung gefunden, sofern eine Gruppe tatsächlich nicht weitere Untergruppen hat.

Innerhalb der Transaktion KOK5 können nicht nur Stammdatenlisten über eine Selektionsvariante erzeugt werden sondern auch über ZUSÄTZE->AUFTRAGSGRUPPE ERZ. eine neue Auftragsgruppe angelegt werden. Direkt ist dieses auch über die Maschinelle Sammelbearbeitung Innenaufträge (Transaktion KOK4) möglich.
 

Exkurs Sammelbearbeitung Innenaufträge

Wobei neben der Anlage von Innenauftragsgruppen hier über die Funktionsauswahl auch andere Möglichkeiten bestehen.

Die Transaktion KOK4 hatte ich im Artikel "Plankopie Innenaufträge" beschrieben, da im Rahmen der Vorbereitungen einer Plankopie über die Funktionsauswahl auch eine Statusänderung (z.B. Sperre von Innenaufträgen) aufgerufen und wieder aufgehoben werden können.

Ebenso kann hier auch eine Löschvormerkung gesetzt werden oder Innenaufträge abgeschlossen werden. Die Änderungsbelege zum Status von Innenaufträgen können unter anderen durch eine Query, wie im Artikel "Änderungsbelege zu Systemstatus (JEST) bei Innenaufträgen per Query auswerten" beschrieben, ebenfalls ausgwertet werden.

Unter der Ablaufsteuerung gibt es den Punkt Auftragsgruppe erzeugen und die Möglichkeit Gruppe und Bezeichnung mitzugeben.

In der Selektionsvariante kann im Feld Auftrag über die Mehrfachauswahl der Button "Upload aus Zwischenablage" gewählt werden und so eine Vielzahl von Innenaufträgen eingefügt werden.

Unsere Überlegung war es nun die bestehenden Einträge über die oben erwähnte Query zur Auswertung der Gruppen mit Einzelwerten auszuwerten um die neuen Elemenente (hinzugekommenen Innenaufträge) zu ergänzen und dann die zu pflegende Gruppe zu löschen und über die KOK4 neu anzulegen und dabei sowohl die neuen als auch die alten Einträge in der Selektionsvariante als Basis zu verwenden.

Fazit und alternative Überlegungen

Zwar ist dieses nicht die eleganteste Möglichkeit, aber die Pflege von entsprechenden Selektionsvarianten (oder Bearbeitung einer temporären Selektionsvariante) ist dann tatsächlich eine brauchbarer Weg, wenn die Anzahl der hinzugekommenen Projekte eine kritische Masse übersteigen.

In der Praxis haben wir uns dann gegen diese Vorgehensweise entschieden, da es letztendlich doch weniger Projekte waren und auch manuell diese schnell eingefügt waren, aber der Austausch über alternative Möglichkeiten ist etwas, dass ich immer wieder sehr schätze und mich persönlich auch regelmäßig freut.

Leider gibt es eine Pflege wie die KOK4 für die PSM-Stammdaten wie Fonds tatsächlich nicht. Hier ist also tatsächlich die direkte Bearbeitung der Gruppe notwendig. Bei Kostenstellen ist die Pflege zumindest der Standardhierarchie über die Transaktion KS12 bzw. KS12N möglich. Hierbei handelt es sich um eine Variante der Transaktion MASS zum Objekttyp BUS0012 Kostenstelle wobei hier bestimmte Daten schon vorbelegt sind.

Isa Bodur von thinkdoforward ist im Beitrag "SAP MASS – so einfach könntest du das Projekt retten." darauf eingegangen.
 

Import und Export per Zusätze und Dateisystem

Eine andere denkbare Alternative war noch der Gedanke innerhalb der Pflegetransaktionen der Gruppe über ZUSÄTZE->IMPORTIEREN beziehungsweise vorher EXPORTIEREN über den Präsentationsserver über eine Export-Datei zu nutzen. Allerdings ist der Aufbau der Datei nicht so ganz ohne und ein Versuch hier die Datei zu bearbeiten.

Vor der Gruppenpflege Kontrolle

Grundsätzlich ist die Frage, wie mit SETS und der Aktualisierung von Stammdatengruppen umzugehen ist, etwas, um das sich wirklich Gedanken gemacht werden sollte, ebenso wie die Frage, ob bestehende Gruppen gelöscht werden oder hin und wieder auch tatsächlich ein Frühjahrsputz ausgeführt wird.

Verknüpfung der Einzelbelege mit entsprechenden Stammdatenlisten

Dieses ist auch der Grund, warum ich oftmals gerne Bewegungsdaten komplett auswerte und diese dann später näher analysiert wird. Zum Beispiel über eine Query, die mir zu den Projekten dann weitere Daten hinzufügt.

So nutze ich hier gerne eine Query zur "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel" oder auch die Nutzung von PSM-FM Finanzierungszwecke.

Im Artikel "PSM-FM Grundlagen Finanzierungszweck im Haushaltsmanagement bei Recherchebericht und Selektion" sind die Grundlagen zur Anlage eines Finanzierungszweckes festgehalten und im Artikel "Grundlagen: PSM-FM Finanzierungszweck (FMFINCODE-FINUSE) im Hochschulberichtswesen für Drittmittelstatistik" ist dieses anhand eines Praxisbeispiel ausführlicher geschildert.

Austausch rund um SAP Empfehlungen aus der Praxis für die Praxis

Sollte jemanden eine andere Vorgehensweise zur Massenpflege von Stammdatengruppen haben, würde ich mich über einen Kommentar sehr freuen. Gerade bei solchen Themen sind einzelne Empfehlungen und Kniffe aus der Praxis sicherlich nicht nur im Bereich Hochschulberichtswesen und Hochschulcontrolling von Interesse.

Hier erhalte ich aber auch so schon hin und wieder im direkten Gespräch, per Mail oder auch auf anderen Wege immer einmal wieder die ein oder andere Anregung. Vielen Dank dafür an dieser Stelle und viele Grüße an die Kolleginnen und Kollegen der hessischen aber auch anderer Hochschulen.

Sogenannte Drittmittelprojekte werden beim Einsatz des Modul PSM Public Sector Management (Öffentlichen Dienst) im FM Funds Management (Haushaltsmanagement) nicht nur auf CO Innenaufträge sondern auch auf Fonds abgebildet die über die FMDERIVE in das Modul bei Buchungen übergeleitet werden.

Gerade durch Themen wie die Mitbuchtechnik und die Überleitung von Buchungen von FI nach CO oder auch in das Modul PSM-FM helfen mir oftmals kleine Kochrezepte in denen einzelne Schritte die zu beachten sind ebenfalls festgehalten werden. Daneben kann natürlich auch Literatur etwas weiter helfen, wobei ich mich hier ebenfalls auf 2019 freue und bis dahin noch gerne auf unser gemeinsames Buch zum Thema Schnelleinstieg ins SAP Controlling (CO) verweise wo die Grundlagen des Controlling mit SAP ebenfalls festgehalten sind.

  Paperback ISBN: 9783960120346

Für 29,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Ebook ISBN: 9783960120346
 

Unter anderen zum Festhalten solcher Punkte nutze ich nun seit etlichen Jahren auch dieses Blog.

Im Artikel "Workflow Kostenstelle und Innenaufträge (Module CO, PSM)" bin ich auf die einzelnen Schritte zur Anlage eines sogenannten Drittmittelprojektes vom Profit-Center über Innenauftrag bis hin zum Fond im Haushaltsmanagement eingegangen.

Nun kann es manchmal erforderlich sein, dass ein Projekt nicht nur gesperrt sondern tatsächlich vollständig gelöscht werden muss. Dieses sollte tatsächlich nur dann erfolgen wenn auch keinerlei Buchungen auf dieses Projekt zu finden sind.

Sinnvoll ist es daher, zum Beispiel mit einen Recherchebericht und/oder Belegjournal zu prüfen ob im Modul PSM Buchungen vorhanden sind. Dieses können sowohl direkte Buchungen, Obligo oder auch Budgetierungen sein. Sofern dieses ausgeschlossen ist und auch im Modul CO keine Buchungen vorhanden sind, kann dieses Projekt in beiden Modulen gelöscht werden.

Kochrezept Löschen von CO Innenauftrag

Hierzu empfiehlt sich folgende Vorgehensweise.

1. Setzen einer Löschvormerkung

Im Modul CO kann über Innenauftrag ändern eine Löschvormerkung in der Transaktion KO02 (Innenauftrag ändern) über BEARBEITEN->LÖSCHVORMERKUNG->SETZEN gesetzt werden. Fermer empfiehlt es sich ebenfalls über BEARBEITEN->SPERRE->SETZEN den Innenauftrag für Buchungen zu sperren. Ist eine Löschvormerkung (LÖVM) gesetzt können keine weiteren Buchungen mehr auf das jeweilige Objekt erfolgen.

Beim Setzen einer Löschvormerkung wird geprüft ob Istbelege oder Obligo vorhanden sind. eine Prüfung auf Planbelege erfolgt dabei nicht.

Damit hat dieses noch höhere Auswirkungen als bspw. TABG (technsich abgeschlossen). Genaueres zum Thema Auftragsstatus ist in oberen Buch zu entnehmen.

2. Löschen PSM-FM Haushaltsfond

Nachdem diese Löschvormerkung gesetzt ist kann im Modul PSM-FM über die Transaktion FM5U Fond ändern über das Menü FONDS->LÖSCHEN das PSM-FM Objekt gelöscht werden.

Damit ist das PSM-FM Objekt Fond nicht mehr im SAP System vorhanden. Nun stellt sich jedoch die Frage, wie das CO Objekt endgültig gelöscht werden kann.

3. Unwiderrufliches Löschen CO Auftrag

Hierzu dient die Transaktion OKO5 "CO Aufträge löschen". Der dahinter liegende Report RKODEL01 löscht alle Innenaufträge (die selektiert werden) unwiderruflich inklusive aller abhängigen Objekte wie Langtext, Änderungsbelege, etc. Dabei erfolgt keine Prüfung ob noch Istkosten oder auch Planbelege vorhanden sind.

Daher ist es sinnvoll die Option "Nur Aufträge mit Löschvorm." zu aktivieren, da damit nur solche Innenaufträge tatsächlich gelöscht werden die eine Vormerkung zum Löschen haben.

Ebenso ist es möglich hier erst einmal einen Testlauf zu starten.

Als Selektionsoptionen stehen hier Aufragsnummer, Auftragsart und Kostenrechnungskreis zur Verfügung.

Exkurs: Löschen von Kostenstellen

Beim Löschen von Kostenstellen über KS02 und hier KOSTENSTELLE->LÖSCHEN kann es zur Fehlermeldung kommen, dass die Kostenstelle nicht gelöscht werden kann, da diese innerhalb eines Zyklus zum Beispiel im Rahmen der Planumlage noch verwendet wird. Hier kann im Kostenstellenstamm (KS03, KS02) über UMFELD->VERWENDUNGSNACHWEISE unter anderen durch den Punkt ZYKLEN IN CO-OM geschaut werden in welche Verrechnungsart (bspw. Umlage) und über welchen Zyklus und Segment die jeweilige Kostenstelle Verwndet wird. Gerade wenn es sich nicht um Sender und Reciever (Sender und Empfänger) sondern um entsprechende Set (Kostnestellengruppen) mit zugeordneten Intervallen handelt muss diese Kostenstelle erst einmal aus den Intervall entfertn werden bevor die Kostenstelle gelöscht werden kann.

 

Fazit

Gerade das Ausführen der Transaktion OKO5 wird oftmals vergessen, so dass hier auch noch Innenaufträge mit gesetzter Löschvormerkung im System vorhanden sind. Ferner ist das Löschen von Stammdaten auch immer ein Thema in Hinblick auf eine geplante Archivierung. Hierbei wird dann zwischen Setzen der Löschvormerkung und endgültiges Löschkennzeichen nach erfolgreicher Archivierung unterschieden.

Das Thema Drittmittel selbst ist noch im Artikel "Drittmittelstatistik nach LOMZ über Recherchebericht und SAP Query" sowie unter "Datentrends für Drittmittelstatistik mit Sparklines ab Excel 2010 darstellen durch Liniendiagramme in Zellen" ein aktuelles Thema, jedoch soll es hier tatsächlich nur um die Behandlung von Stammdatenobjekte in den Modulen CO und PSM-FM gehen. Das Thema Berichtswesen ist sicherlich an anderer Stelle im Blog weiterhin ein Thema ;-).

Sowohl im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" als auch im Kapitel 2.5.2. Klassifizierung im Buch »Berichtswesen im SAP®-Controlling« bin ich ausführlicher auf die Möglichkeiten der Anwendungsübergreifenden Komponente der Klassifizierung von Stammdaten eingegangen.

Hier besteht die Möglichkeit unter anderen die Stammdaten von Fonds im Modul PSM-FM (Public Sector Management - Haushaltsmanagement) oder auch bei Innenaufträgen im Modul CO sowie auch bei Materialstammdaten um eigene Merkmale zu erweitern die als weitere Informationen zum Stammdatum festgehalten werden.

Hier bietet die Klassifizierung innerhalb des Klassensystem eine Vielfalt von weiteren Möglichkeiten die schon beim Auswerten oben in der Query beschrieben sind und besonders für Datumsfeldern wie im Artikel "Query zur Auswertung von Klassifizierungsmerkmale PSM Fonds zu CO Innenauftrag und Datumsfelder mit Konvertierung von FLOAT zu DATUM" beziehungsweise wesentlich eleganter unter "ABAP Anweisung WRITE zum Umwandeln von Variablen und Werten wie FLOAT (Gleitpunktzahl, Fließkommazahl)" erläutert darüber hinaus auch beliebig komplex und in der Auswertung auch kompliziert sein können.

Im Rahmen der Stammdatenauswertung durch eine Query habe ich die Werte zu den einzelnen Merkmalen ausgewertet. Hier werden Inkonsisi

Inkonsistenz der Merkmalbewertung festgestellt

Bei Pflege eines Klassifizierungsmerkmales erhalte ich nun aber die Fehlermeldung "Inkonsistenz der Merkmalbewertung festgestellt" Meldungsnr. C1821. Innerhalb der Klassifizierung (in unseren Fall eines Fond, kann aber auch Innenauftrag sein) kann nun die rechte Schaltfläche Inkonsistenz helfen in der direkt der Wertekonflikt angegeben wird und über den Mülleimer der verursachende Wert direkt gelöscht wird.

Ursache für Inkonsistenz

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 Datenbank ein ehemals gepflegter Merkmalswert hinterlegt ist, 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.

Hierbei wurde in der Merkmalpflege die ebenfalls mögliche Prüfung ignoriert, so dass das ehemaligfe Merkmal nicht mehr vorhanden ist (normalerweise hätte es eine Warnmeldung gegeben, da dieses Merkmal wo verwendet wurde).

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.

Hier zeigt sich erneut einmal wieder die Notwendigkeit von sauber kommunizierte und gepflegte Stammdaten.

Sofern ein Interesse an der Klassifizierung besteht kann ich hier auf folgende Kapitel meines Buches verweisen:

2.5.2    Klassifizierung

• Merkmal pflegen
• Klasse pflegen
• Suche über Klassifizierung

Das Thema ist auch ein Aspekt im Berichtswesen und gerade im Bereich von Drittmittel beim Controlling eine relevante Funktion.

Im Buch »Berichtswesen im SAP®-Controlling« bin ich ausführlich auf dies Thema eingegangen.
  Vielleicht finden sich hier ja auch noch weitere Anregungen für den Aufbau eines Berichtswesen mit SAP nicht nur für CO im Buch.

Ansonsten kann ich auch die Grundlagen der Klassifizierung im folgenden Abschnitt als kurz gehaltenen Exkurs zusammen fassen:

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

Fazit

Auch wenn ich mich derzeit an der Arbeit eher mit der Entwicklung von neuen Berichten sei es nun Report Writer (siehe "Grundlagen Kurzeinführung und Handbuch Report Painter Report Writer") oder SAP Query (siehe "Grundlagen Kurzeinführung und Handbuch SAP Query") sowie eigene Transaktionen (siehe "Transaktion anlegen (Report, Parameter) bspw. für SAP Query / Unterschied Parameter- oder Reporttransaktion") sowie das Thema eCATT und LSMW (siehe "Massenstammdatenpflege mit LSMW oder SECATT dank Transaktionsaufzeichnung - Handbuch erweiterte computergestützte Test-Tool (eCATT) und LSMW") sind doch auch immer wieder Stammdaten ein Thema wo es sich lohnt einen genaueren Blick darauf zu werfen.

Daher bin ich auch immer wieder dankbar sich auch mit solchen Themen mit Kolleginnen und Kollegen austauschen zu können.

Die interessanteren Berichte und eigene Entwicklungen sind oftmals tatsächlich nur durch konkrete Anfragen von Kolleginnen und Kollegen entstanden und selbst im beliebtesten Werkzeug im Werkzeugkoffer des Controlling (gemeint ist eine Tabellenkalkulation wie zum Beispiel Microsoft Excel) gibt es oftmals auch neue Wege die sich dann lohnen zu erforschen und die eigenen Prozesse anzupassen.

Gerade solche Fehlermeldung wie die obere oder auch Anfragen aus benachbarten Modulen wie die Finazbuchhaltung führen nicht nur zum gegenseitigen Lernen sondern manchmal auch zu Artikeln hier im Blog wie auch letztens eine Anfrage aus der Anlagenbuchhaltung dann zum Artikel "Grundlagen Finanzbuchhaltung: Belegart und Buchungsschlüssel als Vorschlagswerte für FI Transaktionen definieren" führte und auch im Bereich des Berichtswesen im Modul des öffentlichen Dienstes (Public Sector Management (PSM) funds management (FM) beziehungsweise im Haushaltsmanagement ist oftmals noch neues durch geänderte ANforderungen zu lernen, wie der Artikel "Negatives Budget in Public Sector Management Haushaltsmanagement buchen (klassische Budgetierung und BCS)" gezeigt hat.

Dies ist auch einer der Gründe warum es mir immer noch wichtig ist, dass sich Keyuser untereinander auch modulübergreifend austauschen können und ein gewisses Maß an gegenseitiger Unterstützung und eben auch voneinander Lernen elementar wichtig ist.

Persönlich kann ich es nur schwer nachvollziehen, wenn der Austausch von Wissen hier nicht als selbstverständlich und tatsächlich von gegenseitigen Nutzen gesehen wird. Auf der anderen Seite steht natürlich auch ein Gegenwert für Wissen und Wertschätzung von Weiterbildung, aber dieses ist vermutlich ein Thema dass in jeden Bereich eine ganz eigene höchst individuelle Dynamik und Motivation hat.

Erstaunlicherweise haben sich auch immer mehr Firmen und auch Hochschulbibliotheken dazu entschlossen die digitale Bibliothek von Espresso Tutorials, die ich unter "SAP Know How" vorstelle ebenfalls als Weiterbildungsinstrument zu nutzen gelernt.

Im IT-Onlinemagazin Artikel "Wie SAP-Anwender neues Wissen aufbauen können: Digitale SAP-Bibliothek" ist die SAP E-Book-Flatrate ebenfalls in Form eines Interviews mit Jörg Siebert vorgestellt. Insbesondere das Angebot für Unternehmen aber auch für Hochschulen ist hier zum Erwerb von Wissen rund um SAP interessant.

Hier freue ich mich auch darüber mit meinen beiden Büchern »Schnelleinstieg ins SAP® Controlling (CO)« von Martin Munzel und mir als auch mein neues Buch »Berichtswesen im SAP®-Controlling« hier ebenfalls gefunden werden zu können.

Die Gliederung von Stammdaten ist in SAP in den einzelnen Modulen unterschiedlich dargestellt.Hier mag ich kurz die Bedeutung von Standardhierarchien im Modul Controlling (CO) mit dem Public Sector Management (PSM) / Haushaltsmanagement - funds management (FM) vergleichen.

Exkurs: Standardhierarchie im Controlling

Im Controlling werden die Kontierungsobjekte Kostenstelle und Profit-Center in den Stammdaten unter den Grunddaten einen Hierarchiebereich zugeordnet. Dabei sind diese Hierarchiebereiche jedoch Stammdatengruppen die sowohl in der Standardhierarchie als auch über Stammdatengruppen gepflegt werden. So können Kostenstellen sowohl über die Transaktion OKEON (Kostenstellenrechnung > Stammdaten > Standardhierarchie > Ändern) aber auch über KSH2 (Stammdaten > Kostenstellengruppen > Ändern) bearbeitet werden. Dabei wird die Standardhierachie immer im Kostenstellenstamm (Transaktion KS01, KS02) zur Auswahl angeboten. Ebenso verhält es sich auch bei der Profit-Center-Rechnung mit den Transaktionen KCH5N bzw. KCH2. Bei den Kostenarten und Konten können hier keine Hierarchien aber ebenfalls Stammdatengruppen über KDH2 oder KAH2 gepflegt werden.Gerade in der Profit-Center-Rechnung ist hier auch ein Schnittpunkt zur Bilanz/GuV im Artikel "Bilanz- GuV- Struktur definieren oder nach CO-PCA kopieren" behandelt.

Auf das Thema Standardhierarchien sind wir im Buch "Schnelleinstieg ins SAP Controlling (CO)" ausführlich eingegangen.

  Paperback ISBN: 9783960126874

Für 19,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Ebook ISBN: 9783960120414
 

Pflege Hierarchie bei PSM-FM Kontierungselemente

Nun stellt sich die Frage, wie sich dieses beim Modul PSM-FM behandelt wird. Im Modul PSM-FM werden die Standardhierarchieen über die Stammdaten von Finanzstelle (entspricht meist Kostenstellen) ebenso aber auch in der Finanzposition gepflegt.

Die Hierarche kann im SAP Menü unter:

• Public Sector Management
• Haushaltsmanagement
• Stammdaten
• Kontierungselemente
• Finanzposition oder Finanzstelle
• Hierarchie
• Standardhierarchie ändern (FMCID) für Finanzpositionen
  Hierarchie bearbeiten (FMSD) bei Finanzstellen

bearbeitet werden. Einfacher ist es jedoch direkt in den Kontierungselementen Finanzstelle / FInanzposition selbst durch Zuordnung  der übergeordneten Finanzstelle im Register Hierarchie. Ebenso ist dieses bei der übergeordneten Finanzposition im Abschnitt "Hierarchiezuordnung" durch die übergeordnete Fiannzposition.

Exkurs: Berichtswesen im PSM-FM

Diese Zuordnung wirkt sich allerdings auch sehr auf das Berichtswesen im PSM-FM aus. Im Artikel "»Rechercheberichte de lux« im Modul PSM FM Haushaltsmanagement" bin ich ja schon auf im Hochschulcontrolling genutzte Budgetberichte und im Artikel "Kundeneigene Transaktionen zu Berichten in PSM FM Haushaltsmanagement zum Beispiel Belegjournal anlegen (Variantentransaktion)" auf die Einzelpostenberichte im Belegjournal eingegangen. In beiden Berichten werden bestimmte Vorgaben (Finanzpositionen oder andere Selektionskriterien) schon beim Aufruf des Berichtes direkt zugewiesen so dass hier zum Beispiel nur Personalausgaben ausgewertet werden.

Klassische Budgetierung und Finanzpositionenhierarchie

Gerade bei der klassischen Budgetierung wird die Hierarchie insbesondere der Finanzpositionen sehr gerne genutzt, was auch im Artikel "SAP PSM-FM klassische Budgetierung mit unterschiedlichen Budgetversionen" erklärt wird. HIer ist eine Besonderheit, dass nicht nur die direkten Kontierungsobjekte bebucht werden sondern neben den Erfassungsbelegen auch Hierarchiebelege geschrieben werden.

Bei der Analyse der Budgetberichte (Einzelposten der Budgetbuchungen über den Hierarchiebeleg) helfen die im Artikel "Einzelposten Klassische Budgetierung Hierarchiebelge"  und für die Sender-Empfänger  Beziehung der Artikel "Sender und Empfänger anhand des Hierarchiebeleg in der klassischen PSM-FM Budgetierung" vorgestellten Auswertungsmöglichkeiten weiter.

So können über die Finanzposition AUFW.PERS alle untergeordneten Finanzpositionen mit Bezug zu dieser ausgwertet werden. Im Beispiel sind das alle Personalaufwandskonten. Ebenso verhält es sich bei der Finanzposition AUFW.SACH und die Sachmittelaufwendungen. Gerade im Recherchebericht ist dieses sehr praktisch und wird häufig zum Beispiel für eine "Saldenliste für Fonds im Haushaltsmanagement Saldo gegen Ertrag und Saldo gegen Budget" angewandt.  Hier können die einzelnen Merkmale wie Finanzstelle, Fond, Finanzposition, Werttyp etc. unterschiedlich dargestellt werden.

Dabei ist diese Darstellung auch im Artikel "Grundlagen Rechercheberichte Ausgabeart grafische Berichtsausgabe oder klassische Recherche" behandelt worden.

Ober und untergeordnete Kontierungselemente

Sowohl im Recherchebericht als auch im Belegjournal sollte jedoch darauf geachtet werden, dass es hier die Option "Untere Kontierung" gibt, die beim Auswerten sich eben nicht nur auf die Hierarchie der Finanzpositionen sondern auch auf die Finanzstellenhierarchie bezieht. Es werden zu den Kontierungselementen der Selektionskriterien im Bericht die hierarchisch untergeordneten Finanzpositionen mit ausgewertet. Dieses bedeutet, dass zu AUFW.PERS auch alle 62* Finanzpositonen als Beispiel ausgewertet werden.

Problem: Auswertung von Finanzstellen die nicht in der Finanzstellengruppe erfasst waren

Ein Kollege sprach mich darauf an, dass sie eine neue Finanzstelle innerhalb eines Fachbereichs mit einer anderen Nummer zugeordnet hatten und beim Auswahl der Finanzstellengruppe für den Fachbereich selbst Finanzstellen die eben nicht nur die Fianzstellen 1080000 bis 1089999  sondern auch die neuen Finanzstellen 8080000 bis 8089999 mit ausgewertet haben, obgleich diese gar nicht in der Finanzstellengruppe mit ausgewiesen waren.

Exkurs Finanzstellengruppe und Auswertung von Stammdatengruppen

Eine Finanzstellengruppe kann unter

• Public Sector Management
• Haushaltsmanagement
• Stammdaten
• Kontierungselemente
• Finanzstelle
• Finanzstellengruppe
• über
  Anlegen (Transaktion FM_SETS_FICTR1)
  Ändern (Transaktion FM_SETS_FICTR2)
  und per FMRP_FC_SET_HIER als Gruppenhierarchie aus der Finanzstellenhierarchie erzeugt werden

Dabei werden, wie auch bei Kostenstellen die Finanzstellen als Intervalle oder Einzelsets als Gruppen zugeordnet und können hier auch ausgwertet werden. Ebenso steht dieses für Finanzpositionengruppen (FM_SETS_FIPEX1  FM_SETS_FIPEX2 und FMRP_CI_SET_HIER) sowie für Fonds möglich.

Im Artikel "Auflösen von Stammdatengruppen nach Einzelwerten - Einzelwerte zu Sets" bin ich auf die Frage eingegangen wie diese erzeugten oder angelegten Stammdatengruppen ausgwertet werden können. Mit Excel kann dann im Artikel "Prüfung inwieweit ein Wert, bspw. eine Kostenstelle, innerhalb eines Intrevalls (Gruppe) liegt in Excel" diese Auswertung genutzt werden um eine Zuordnung zum Beispiel bei Einzelposten auf die zugeordnete Stammdatengruppe zu bekommen. Dieses aber nur am Rande....

Lösung: "untere Kontierung" beim Belegjournal und Recherchebericht führt zur Auswertung innerhalb der Finanzsellenhierarchie

Nach einen kurzen Telefonat hat sich dieses dann aber doch geklärt.... Innerhalb der Finanzstellengruppe war auch eine dreistellige Finanzstelle 108 enthalten die in der Anfangszeit dafür genutzt wurde Budget dorthin zu buchen und dieses dann auf die einzelnen Finanzstellen zu verteilen. Durch die Markierung von "untere Kontierung" wurde aber auch die Finanzstelle 808* die ebenfalls innerhalb der Finanzstellenhierarchie der Finanzstelle 108 zugeordnet waren mit ausgewertet.

Mittlerweile wird das Landesmittelbudget jedoch direkt auf die richtigen Finanzstellen gebucht, so dass die Finanzstelle 108 problemlos aus der Finanzstellengruppe entfernt werden konnte.

Grundsätzlich könnte natürlich auch die Finanzstellenhierarchie angepasst werden (flache Hierarchie oder neue Knoten) aber dann ist, wie im Artikel "Reorganisation von Finanzstellenhierarchien" beschrieben auch ein Neuaufbau des Budgets erforderlich.

Manchmal sind solche geschilderten Probleme tatsächlich bestens dazu geeignet scih wieder einmal intensiver mit der Problematik von Hierarchien und Grundlagen im Modul PSM-FM zu beschäftigen. Sehr hilfreich ist hier auch einen Geschäftsprozess zum Anlegen dieser Kontierungselemente zu haben. Daher hatte ich mir vor einigen Jahren die einzelnen Schritte zum Anlegen im Artikel "Workflow Kostenstelle und Innenaufträge (Module CO, PSM)" aufgeschrieben. Da mit Einführung des neuen Budgetverteilungssystem BCS (siehe Artikel "PSM Haushaltsmanagement Budgetverwaltungssystem BCS oder klassische Budgetierung") eine andere Technik im PSM-FM eingesetzt wird und im Gegensatz zur klassischen Budgetierung nicht mehr Hierarchiebelege geschrieben erden können bestimmte Probleme hier möglicherweise zumindest für eine Budgetauswertung zur Seite gelegt werden. Aber die Bedeutung der Stammdatenhierarchie bei der Selektion in Berichten dürfte weiterhin relevant bleiben.

Von daher bleibt es bei SAP auch im Bereich der öffentlichen Verwaltung spannend und es hilft hier sich beim Aufbau oder Arbeit im Berichtswesen auch um die Stammdaten weiterhin Gedanken zu machen. Die ein oder andere Anregung kann dabei vielleicht auch aus unterer Buchvorstellung entnommen werden. Viele der dort vorgestellten Berichtstools sind auch außerhalb des Modul CO zum Beispiel im PSM-FM und damit im Berichtswesen im Haushaltsmanagement nutzbar.

  (01. Juni 2017)
Paperback ISBN: 9783960127406

Für 19,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *


Auch hier freue ich mich selbstredend wenn diese ebenfalls vor Ort eingesetzt werden kann. Ansonsten kann ich aber auch das Thema Weiterbildung im Rahmen von SAP Know How empfehlen. Auch ansonsten sollte hier auf der Seite in nächster Zeit noch das ein oder andere Thema angesprochen werden.

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

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

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

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

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

Verknüpfung von CO Innenauftrag und PSM Fond

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

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

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

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

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

ZAUFNR mit fester Länge der Projektnummer des Innenauftrag

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

ZAUFNR = AUFK-AUFNR+4(8).

Hierbei bedient sich das Coding der Technik eines Offsets.

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

ZAUFNR mit festzulegender Länge der Projektnummer

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

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

DATA L_AUFNR  type i.
DATA L_OFFSET type i.

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

L_AUFNR = 8.

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

L_OFFSET = 12 - L_AUFNR.

* Maximial 12 Zeichen sind in AUFK-AUFNR vorhanden

ZAUFNR = AUFK-AUFNR+L_OFFSET(L_AUFNR).

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

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

Stammdaten Fond ergänzen per Zusatztabelle FMFINCODE

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

Ein wichtiger Punkt ist dabei die Reihenfolge der Codingabschnitte.

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

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

Zusatztabelle FMFINCODE

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

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

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

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

WHERE FIKRS  =  AUFK-BUKRS

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

AND FINCODE = ZAUFNR

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

Klassifizierungsmerkmal aus AUSP auswerten

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

Welche Merkmale sind vorhanden?

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

Eines dieser Merkmale ist die Projektbewertung PBW.

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

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

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

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

AUSP-OBJEK Objektnummer mit vorgegebenen Finanzkreis

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

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

CONCATENATE 'KRK ' ZAUFNR INTO L_OBJFOND RESPECTING BLANKS.

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

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

Objektnummer aus Buchungskreis identisch zum Finanzkreis ermitteln

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

Hierzu habe ich das Coding an einer Zeile angepasst.

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


CONCATENATE  AUFK-BUKRS ZAUFNR INTO L_OBJFOND RESPECTING BLANKS.


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

Durch die Codingzeile:

CONCATENATE  AUFK-BUKRS ZAUFNR INTO L_OBJFOND RESPECTING BLANKS.

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

Datentyp beim Klassifizierungsmerkmal Unterschied AUSP-ATWRT und AUSP-ATFLP

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

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

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

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

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

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

Gleitpunktzahl FLOAT in Datum (DATE) konvertieren

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

Datum als Float

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

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

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

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


CONCATENATE  AUFK-BUKRS ZAUFNR INTO L_OBJFOND RESPECTING BLANKS.


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

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

Funktionsbaustein CTCV_CONVERT_FLOAT_TO_DATE

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

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

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

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

 

Float in Integer und Integer in Datum umwandeln

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

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

DATA
ZL_integer TYPE I,
ZL_datum TYPE D.

ZL_integer = ATFLV1.

WRITE  ZL_integer TO  ZL_datum.

DATUM2 = ZL_DATUM.

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

Umwandeln ATFLV in Datum durch lokale Felder in Query

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

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

• SPRINGEN
• FELDAUSWAHL
• FELDAUSWAHL

möglich indem über

• BEARBEITEN
• KURZBEZEICHNUNGEN
• EIN/AUSSCHALTEN

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

Nun ist es erforderlich über

• BEARBEITEN
• LOKALE FELD
• ANLEGEN

mehrere lokale Zusatzfelder mit Formeln und Bedingungen anzulegen.

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

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

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

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

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

und als Berechnungsvorschrift
DATUM
bei der Bedingung
DATUM<>0

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

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

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

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

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

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

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

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

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

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

Felder zum Auswertung AUSP-ATFLV

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

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

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

Query zur Auswertung ATFLV1 aus FLOW wird DATE

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

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

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

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

 

---

Hinweis:

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

---

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

Zur Erinnerung Query und Infoset zur Abrechnungsvorschrift:

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

Exkurs Objektnummer oder Partnerobjektnummer

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

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

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

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

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

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

Nun können als Empfänger die beiden Felder

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

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

Senderauftrag und Empfängerauftrag in der Selektion zur Auswertung eintragen

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

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

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

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

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

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

---

Hinweis:

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

---

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

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

Kreditoren Einzelposten Liste im Modul FI

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

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

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

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

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

Das entsprechende Infoset ist in folgender Abbildung dargestellt:



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

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

Aus Kostenstellenschlüssel den Fachbereich oder Abteilung auslesen

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

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

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

Die Aufgabe wäre nun also:

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

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

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

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

In der Query sind folgende Felder enthalten:

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

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

Infoset über Zusatztabellle erweitern

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

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

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

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

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

HINWEIS Vorteil Zusatztabelle versus Join

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

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

Als Beispiel habe ich dabei folgende Felder mit übernommen:

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

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

Query mit lokalen Zusatzfeldern für Ermittlung Fachbereich

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

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

Bezeichnungen und mit lokalen Feldern arbeiten

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

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

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

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

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

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

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

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

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

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

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

Sonst
''

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

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

Lokales Zusatzfeld KSIA zum Ausweis jedglicher Kostenstelle

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

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

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

Grundliste Query Kreditoren Einzelposten mit Gruppierung Bereich und Kostenstellen

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

lokale Zusatzfeld
Fachbereich  (L)
Kostenstelle KSIA  (L)

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

Zusatzfelder
Text: Belegart  (L)  TEXT_GLPCA_BLART

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

SKAT
Sachkontolangtext (L) SKAT-TXT50

EC-PCA: Ist-Einzelposten (GLPCA)
Betrag in Buchungskreiswährung (L) GLPCA-HSL
(sinnvoll kann es sein hier als Währungsfeldposition "kein Währungsfeld" zu markieren, sofern nur mit einer Währung bspw. EUR gearbeitet wird)
Positionstext (L) GLPCA-SGTXT
Kostenstelle (L,S) GLPCA-KOSTL
Innenauftrag (L,S) GLPCA-AUFNR

AUFK
Auftragkurztext (L) AUFK-KTEXT
Verantwortliche Kostenstellle (L) AUFK-KOSTV

Damit habe ich dann tatsächlich alle für unsere Auswertung erforderliche Daten vorhanden.

ALV Liste Gruppieren und Zwischensummen

In der ausgeführten Query kann ich dann über die Schaltfläche Zwischensummen für die Felder Fachbereich und Kostenstelle KSIA sowohl Sortierung als auch Zwischensummen  aktivieren und habe damit eine Liste mit Zwischensummen über die gebuchten Beträge.

Sobald eine solche Zwischensumme gebildet wurde, kann aber über den Zauberwürfel (Layout auswählen und hier die Auswahl im Ausklappmenü auf Layout ändern) aus den Spaltenvorrat die nun vorhandene Spalte Zähler mit in die angezeigten Spalten übernommen werden und man hat sowohl für die Kostenstellen (inklusive der verantwortlichen Kostenstelle der Projekte) als auch auf Ebene der Fachbereiche eine Summe aller Buchungen mit ausgewiesen.

Summenaufrissstufen in ALV Liste wählen

Über die Schatfläche Zwischensumme kann das Menü Aufrisssummenstufe gewählt werden und hier eine Zwischensumme auf Ebene

• 0 Nicht-Summenzeilen
• 1 Kostenstelle KSIA
• 2 Fachbereich

gewählt werden. Hier werden je nach Stufe die tieferliegenden Positionen zugeklappt, so dass zum Beispiel bei der Option 2 nur die Anzahl der Belege auf Ebene der Fachbereiche ausgewiesen werden.

Im Ergebnis sieht man nun Buchungsvolumen sowie in Form der Beträge als auch der Anzahl der Buchungen.

Durch die Selektion der Belegart können nun auch Zahlungen (ZP) unberücksichtigt bleiben (ausgefiltert werden) oder auch einzelne Belegarten direkt in der Selektion der Query gewählt werden.

Fazit

Auf diese Weise kann also relativ einfach das Buchungsvolumen betrachtet werden aber gleichzeitig ist dieses auch ein Beispiel dafür, wie ich selbst das Blog hier nutze um aus bestehenden Lösungen auch neue Probleme direkt zu lösen.

Damit trage ich sozusagen zu meinen eigenen SAP KnowHow bei, da ich die Lösung mit den lokalen Zusatzfeldern im ersten Moment auch nciht mehr in Erinnerung hatte. Aber dafür gibt es ja glücklicherweise die Artikelsuche im Blog ;-).

Belege zählen im FI Belegjournal

Selbstverständlich ist die beschriebene Vorgehensweise nur ein Weg um an ein Ergebnis zu kommen. Für die Fragestellung mit Kreditorenbelege war die Vorgehensweise schon durch die vorhandene Query und den gewohnten Umgang mit ihr recht naheliegend. Sollen jedoch alle Belege eines Bereiches gezählt werden würde ich die lokalen Zusatzfelder eher innerhalb der mehr in der Finanzbuchhaltung angesiedelten "Query FI Einzelposten als Belegjournal - Belegsegment (BSEG) und Belegkopf (BKPF) verknüpfen" einbinden und mich hier nicht der Nebenrechnung bzw. des Ledger der Profit-Center-Rechnung widmen.

Analyse sprechender Nummernschlüssel in SAP Query

Grundsätzlich hat die Übersetzung von sprechenden Nummernkreise tatsächlich das Potential innerhalb einer Query eine ausführlichere Analyse zu machen. Unter "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel" habe ich dieses für Innenauftragsnummern beschrieben und hier auch im Artikel "Drittmittelstatistik nach LOMZ über Recherchebericht und SAP Query" dieses auch für weitere Merkmale genutzt.

Feedback auf meiner Facebook Seite

Das Thema Ausweis Fachbereich werde ich in einen der folgenden Artikeln noch einmal aufgreifen (dann allerdings mit Lehreinheitsbezeichnung) und dabei auch auf das Thema ABAP Code in Excel generieren etwas näher beschreiben. Wobei ich hier schon auf Facebook Ende letzten Jahres (siehe Beitrag auf facebook.com/unkelbach) wirklich hilfreiches Feedback erhalten habe.

Wo ich gerade Facebook anspreche. wer mag kann auch gerne, so auf Facebook angemeldet eine Bewertung für meine Seite abgeben.

 

---

Hinweis:

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

---

In der Stammdatenpflege von CO Innenauftrag (Transaktion KO02), Kostenstelle (Transaktion KS02) oder auch bei Kostenarten (Transaktion KA02) besteht die Möglichkeit neben einer Beschreibung auch für die einzelnen Beschreibungen einen Langtext zu pflegen.

Langtextpflege zur Beschreibung von Innenauftrag oder Kostenstelle

Hierzu ist die entsprechende Schaltfläche neben der Beschreibung anzuklicken (Langtext anzeigen bzw. pflegen) und es kann für einzelne Sprachen eine ausführliche Beschreibung zum CO Objekt hinterlegt werden.

Eventuell muss hier noch die zu pflegende Sprache des Feldes gewählt worden.

Danach können hier im SAP Editor ausführlichere Informationen (zum Beispiel Historie bei sich ändernden Kostenstellenbezeichnungen oder sonstige ausführliche Informationen zum CO Objekt) hinterlegt werden.

Da hier mehr als eine Zeile zur Verfügung steht ist dies eine gerne genutzte Stelle für ausführliche Informationen zum jeweiligen Objekt.

Bisher war hier immer ein Editor in SAP aufgerufen und man konnte über

• SPRINGEN
• EDITOR WECHSELN

auf einen Zeileneditor wechseln. Dieser Punkt ist noch immer möglich, jedoch wird nun statt eines SAP Editor ein in SAP eingebundenes MS Word (Winword) eingebunden mit reduzierten Schaltflächen in dem die Texte bearbeitet werden können.

MS Word als Editor für SAP Script

Seit SAP ERP [Central Component (ECC)] 6.2 Enhancement Package 42 ist es möglich MS Word als Editor für SAP Script bzw. Smart Forms zu aktivieren. Ab aktuelleren Releases kann nur noch MS Word als Editor für SAP Script bzw. Smart Forms verwendet werden.

Grundsätzlich sollte in der Transaktion I18N Internationalisierung unter den Punkt I18N Customizing durch die Option MS Word als Editor möglich auf Word als Editor zu wechseln.

Dieses ist neben SAP Script und Smart Forms auch erforderlich um Standardtexte zum Beispiel in der Transaktion SO10 für den Anmeldehinweis beim Anmeldeschirm von SAP zu bearbeiten (siehe hierzu auch im berater-wiki.de unter "Pflege SAPscript-Textbausteine mit Transaktion SO10 (ID = ST)").

Eine Deaktivierung von MS Word als Editor für SAPscript und Smart Forms scheint allerdings nur noch per ABAP Report möglich zu sein. Hierzu muss mit der Transaktion SA38 der Report RSCPSETEDITOR gestartet werden.

Danach erfolgt eine Auswahl in der für

• SAPScript
• Smart Forms

festgelegt werden kann, dass hier MS Word als Editor verwendet werden soll.

Sofern diese Option aktiviert oder deaktiviert muss diese Option noch über die Schaltfläche "Aktivieren" aktiviert und damit produktiv geschaltet werden.

Diese Einstellung ist eine laufende Einstellung zu der kein Transportauftrag erstellt wird. Die Einstellung selbst wird in der Tabelle TCP0I "Parametertabelle für i18n-Systemkonfiguration" in den Feld sapscript_editor beziehungsweise. smartforms_editor im Feld Name ("Parameter fuer I18n Systemkonfiguration") und im Feld Value ("Wert für i18n-Systemkonfigurationsparameter (TCP0I-Wert)") mit der Ausprägung MSWord festgealten.

Ferner sind in dieser Tabelle auch letzte Änderer (LASTUSER) und Zeitpunkt der Änderung (TIMESTAMP) festgehalten.

Fazit

Da es bis auf die neue Ansicht kaum Funktionseinschränkungen bei der Nutzung von MS Word zur Pflege der Langtexte gibt und künftig SAP Script nur noch über MS Word gepflegt werden kann, ist es vielleicht tatsächlich empfehlenswert hier sich mit der neuen Oberfläche anzufreunden.

Interessant ist aber tatsächlich an welche Stellen SAP Script eingesetzt wird. Mir war die Textpflege bisher nicht bewusst als SAP Script Anwendung aufgefallen, was aber möglicherweise auch daran liegen mag, dass ich bisher nicht bewust mit SAP Script gearbeitet habe. Negativ aufgefallen wäre es mir vermutlich eher, wenn im Report Painter oder bei Rechercheberichten die Pflege der Kopfzeile davon betroffen wäre.

Gerade hier nutze ich, wie auch schon im Artikel "Grundlagen Kurzeinführung und Handbuch Report Painter Report Writer" sehr gern die Möglichkeit der Arbeit mit weiteren Texten. Zugegeben sind hier aber keine weiteren Sprachversionen zu pflegen. Gleiches gilt auch für andere von mir gerne genutzten Auswertungstool in SAP, die ich aber auch schon im Artikel "Unterschiedliche Auswertungsmöglichkeiten im Controlling (Report Writer, Recherchebericht, SAP Query) und natürlich Excel ;-)" zusammengestellt habe und auf die ich im Verlauf des Jahr 2017 sicher erneut noch einmal zurück kommen werde.

Bis dahin zeigt sich aber gerade an einen solchen Beispiel, wie sinnvoll der Austausch zwischen SAP Basis und den anderen Modulverantwortlichen (Keyusern) sein kann, so dass hier die Verwunderung über eine neue Oberfläche in SAP nicht allzu groß ist.

Werbung:
Nebenbei in der digitalen SAP Bibliothek von Espresso Tutorial (siehe auch SAP Know How)  sind auch Bücher wie "Praxishandbuch SAPscript für SAP ERP" oder "Praxisbuch SAP® Interactive Forms und Adobe® LiveCycle Designer" (Amazon Partnerlink) enthalten, so dass sich auch in dieses Thema vertieft werden kann :-)

Im Artikel "Stammdatenerweiterung von CO-Objekten am Beispiel ergänzende Kostenstelle beim Innenauftrag" wurde schon die Stammdatenerweiterung von Kostenarten, Kostenstellen und Innenaufträgen per Userexit (CMOD) beschrieben. Hierdurch sind bei Kostenstellen (bspw. über die Pflegetransaktionen KS01 Kostenstelle anlegen, KS02 Kostenstelle ändern und KS03 Kostenstelle anzeigen) sowie für Kostenarten (ebenfalls hier über die Transaktionen KA01, KA02, KA03)  die Registerkarte Zusatzfelder vorhanden über die die angelegten kundeneingene Felder gepflegt werden können.

Zusatzfelder per Gruppenrahmen im Auftragslayout CO Innenauftrag aktivieren

Lediglich zur Nutzung der Zusatzfelder für den CO Innenauftrag ist noch Customizing erforderlich, so dass die Felder genutzt werden können. Hierzu muss im Auftragslayout der Gruppenrahmen 09 kundeneigener Felder einer Registerkarte zugeordnet werden.

Dieses kann im Customizing über die Transaktion SPRO unter folgenden Pfad erfolgen:

• Controlling
• Innenaufträge
• Aufragsstammdaten
• Bildschirmgestaltung
• Auftragslayout definieren

Hier können entsprechende Registerkarte für die CO Innenauftragspflege definiert werden und innerhalb eines Register der Gruppenrahmen 09 Kundeneigene Felder zugeordnet werden. Dieses Auftragslayout kann dann einzelnen Auftragsarten zugeordnet werden.

Zusammenhang Auftragsart - Auftragslayout

Sofern einer Auftragsart kein Auftragslayout zugeordnet ist, werden ohnehin alle Felder zur Pflege angeboten. Keine Regel ohne Ausnahme, sofern innerhalb des Auftragslayout über die Feldauswahl einzelne Felder ausgeblendet werden ist dieses nicht der Fall.

In diesen Beispiel soll aber tatsächlich das Auftragslayout genutzt werden. Entsprechend ist auch hier im Customizing die Auftragsart mit dem angelegten Auftragslayout verknüpft.

Dieses ist wiederum im Customizing (Transaktion SPRO) unter

• Controlling
• Innenaufträge
• Auftragsstammdaten
• Auftragsarten definieren

beziehungsweise mit der Transaktion KOT2_OPA möglich.

Eine ausführliche Beschreibung zum Thema Auftragslayout und Auftragsart ist auch in Buch "Schnelleinstieg ins SAP Controlling (CO)" geschildert :-)

Nun stellt sich aber die Frage, welche Auftragsarten nun eigentlich welchen Auftragslayout zugeordnet sind. Dieses kann relativ einfach über die Tabelle T003O "Auftragsarten" zum Beispiel über eine SAP Query anhand der Tabellenfelder in folgender Tabelle ausgewertet werden.

Auswertung Auftragsart und Auftragslayout

Beschreibung	Technischer Name	L	S
Auftragsart	T003O-AUART	X	X
Zusatzfeld Text Auftragsart	TEXT_T003O_AUART	X
Auftragslayout	T003O-LAYOUT	X

Dabei sind L als Listenfeld und S für Selektionsfelder vorgesehen.
Anhand dieser Query kann relativ schnell festgestellt werden, welche Auftragsarten und welches Auftragslayout zur Nutzung der Zusatzfelder angepasst werden muss.

Auswertung Zusatzfelder in Stammdatenlisten (KA23, KS13, KOK5)

Im Stammdatenverzeichnis für Kostenarten über die Transaktion KA23 oder für Kostenstellen über die Transaktion KS13 kann durch Nutzung der Option Selektionsvariante im Abschnitt Zusatzfelder anhand der Schaltfläche Zusatzfelder die kundeneigene Felder über eine freie Abgrenzung genutzt werden.

Im Unterschied dazu ist im Stammdatenverzeichnis für Innenaufträge (Transaktion KOK5) direkt eine Schaltfläche "kundeneigene Felder" nach Auswahl der Option Selektionsvariante vorhanden über die ebenfalls diese freie Abgrenzung erfolgen kann.

Auswertung Stammdatentabelle zum Beispiel per SAP Query

Eine weitere Frage ist, wie die neuen Stammdatenfelder in SAP Query oder in den Tabellen ausgewertet werden können.

Hierbei sind in den einzelnen Tabellen die Zusatzfelder als Customer Include der Stammdatentabelle hinzugefügt. Dieses kann auch in der Transaktion SE12 näher betrachtet werden.

In folgender Tabelle habe ich die Stammdatentabellen und das Include mit aufgeführt.

CI Zusatzfelder

CO Objekt	Tabelle	Include	Bezeichnung
Innenauftrag	AUFK	CI_AUFK	Zusatzfelder CO-Innenauftrag
Kostenstelle	CSKS	CI_CSKS	Zusatzfelder Kostenstelle
Kostenart	CSKB	CI_CSKB	Zusatzfelder Kostenart

Für ein Infoset bietet es sich an, diese Felder aus der Stammdatentabelle dann einer eigenen Feldgruppe zuzuordnen, so dass die Felder dann leicht gepflegt werden können und entsprechend in der Query genutzt werden können.

Werden diese Tabellen in einer Query genutzt werden die Zusatzfelder wie normale Tabellenfelder durch den CustomerINclude (CI) zur Verfügung gestellt.  Somit lassen sich auch die entsprechenden Query problemlos anpassen.
 

---

Hinweis:

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

---

Einer der Vorteile bei der Erstellung einer Drittmittelstatistik auf Basis einer leistungsorientierten Mittelzuweisung (LOMZ) Definition von einzelnen Drittmittelgebern über einen Recherchebericht (siehe "Saldenliste für Fonds im Haushaltsmanagement Saldo gegen Ertrag und Saldo gegen Budget") ist dass hier der Finanzierungszweck ergänzend zu den einzelnen Finanzpositionen (zum Beispiel über alle innerhalb der Hierarchie der Finanzpositionen der Finanzposition ERTRAEGE zugeordneten Finanzpositionen) als einzelnen Spalten definiert werden können. Auf diese Weise können alle Erträge vom Bund (einzelnen Finanzierungszwecke) kombiniert mit den Einnahmen ausgewiesen werden.

Damit werden alle Fonds entsprechend ihres Mittelgebers ausgewiesen. Ergänzend dazu könnten noch einzelne Finanzpositionen ohne Zuordnung eines Finanzierungszweckes ausgewiesen werden, so dass auch Einnahmen die auf Kostenstellen bzw. Finanzstellen oder aber Fond WIPLAN (zur Abbildung des Landeshaushalt) so zum Beispiel Geldspenden ausgewiesen werden.*

Im Artikel "Kundeneigene Transaktionen zu Berichten in PSM FM Haushaltsmanagement zum Beispiel Belegjournal anlegen (Variantentransaktion)" hatte ich schon etwas ausführlicher beschrieben, wie ein solcher Bericht (neben Einzelpostenlisten) in einer vorgegebenen Variante als kundeneigene Transaktion ausgerollt werden kann. Besonders bei Rechercheberichten bietet sich hier auch der Artikel "Parametertransaktion für Recherchebericht" zum Nachlesen an.

Nehmen wir nun aber einmal an, dass ein Finanzbericht über alle Projekte (sowohl Drittmittel als auch diverse Sondermittel) berichtet werden sollen, dann kann es sinnvoll sein hier die Definition von LOMZ fähigen Drittmitteln und andere Projekten nicht nur anhand des Finanzierungszwecks sondern auch über andere Merkmale zu definieren.

Im Anwendungsfall sind Mittel Dritter (Drittmittel) über ein Nummernintervall als für die Drittmittelstatistik relevant festgelegt und eine Teilmenge davon ist als Dienstleistungsprojekt (reine Anwendung gesicherter Erkenntnisse) nicht als LOMZ-relevant identifizierbar. Hierzu wurde in der Klassifizierung ein Merkmal PBW für die Projektbewertung definiert und dieses entsprechend mit den Wert DL versehen. Eine Auswertung von Merkmalen der Klassifizierung ist beispielsweise im Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" oder aber mit Grundlagen zur Klassifizierung auch im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" beschrieben.

Sprechende Nummernschlüssel bei Stammdaten

Kleiner Hinweis am Rande, das Thema sprechende Nummernschlüssel wurde sehr ausführlich in unseren Buch
 

Schnelleinstieg ins SAP-Controlling (CO)

Autoren: Andreas Unkelbach, Martin Munzel

Verlag: Espresso Tutorials GmbH

1. Auflage (01. November 2015)

Paperback ISBN: 9783960126874

Für 19,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Ebook ISBN: 9783960120414
 
diskutiert und zeigt hier tatsächlich unterschiedlichste Ansätze in der Stammdatenkonzeption, aber dieses nur am Rande.

Um nun über Nummernkreis und Merkmale der Klassifizierung die Drittmittel entsprechend einzuordnen bedarf es drei Zusatzfelder im Infoset.

Vorbedingung: Auswertung PSM und CO Stammdaten

Als erstes müssen, erneut, die Stammdaten von CO mit PSM verknüpft werden.

Innerhalb des Abschnitt "Zusatzfeld ZAUFNR (Übernahme AUFK-AUFNR als FMFINCODE-FINCODE" im Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" wurde nun eine clevere Alternative dargestellt.

Zusatzfeld ZAUFNR zur Verknüpfung von Innnenauftrag und Fond

Hierzu wurde das Zusatzfeld ZAUFNR mit per LIKE-Referenz FMFINCODE-FINCODE erstellt was in den folgenden Abschniten als Hilfsfeld genutzt werden kann.

Als erläuternde Überschrift und Langtext kann "Auftragsnummer 10 stellig" genommen werden.

Das in meinen Augen clevere Coding beschränkt sich auf einen Einzeiler in dem dem Feld per Offset die Auftragsnummer aus der Tabelle AUFK zugewiesen wird.

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

ZAUFNR = AUFK-AUFNR+4(8).

Hierbei bedient sich das Coding der Technik eines Offsets.

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

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

Im Ergebnis haben wir nun das Feld ZAUFNR, welches die gleichen Eigenschaften wie das Feld FINCODE innerhalb der Tabelle FMFINCODE hat.

Nun kann das Feld für verschiedene Formen der Verknüpfung genutzt werden.
 

Merkmal aus Klassifizierung zur Projektbewertung mit auswerten

Nehmen wir an, dass im Rahmen der Klassifizierung von Fonds im Modul PSM-FM die Projektbewertung in ein Merkmal festgehalten wird. Dann ist auch die im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" erheblich erleichtert.

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

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

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

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


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

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

CONCATENATE  'KRK ' ZAUFNR INTO L_OBJFOND RESPECTING BLANKS.

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

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

LOMZ relevante Drittmittel

Nun kommt allerdings die Zuordnung über die Projektnummer in Kombination zu der Projektbewertung. Hierzu wird die gleiche Programmlogik verwendet wie im Artikel "Auswertung sprechender Nummernkreisintervalle von CO Innenaufträgen mit Query Zusatzfeldcoding und Unterscheidung numerischer oder alphanumerischer Schlüssel" allerdings beschränkt auf einen Nummernkreis der Drittmittelprojekte sowie einen Bezug auf die Projektbewertung über das Feld PBW.

Hierzu wurde ein Zusatzfeld LOMZ mit den Eigenschaften LIKE AUSP-ATWRT im letzten Codeabschnitt des Infoset (hier Reihenfolge des Codeabschnitts 4) angelegt.

Das zugehörige Coding zum Zusatzfeld sieht dabei wie folgt aus:
 

CLEAR LOMZ.
IF AUFK-AUFNR CO  '1234567890'.
  IF AUFK-AUFNR => '000032000000' AND AUFK-AUFNR <= '000032999999'.
    CASE PBW.
      WHEN 'DL'.
        LOMZ = 'DL'.
      WHEN OTHERS.
        LOMZ = 'LOMZ'.
    ENDCASE.
  ENDIF.
  IF AUFK-AUFNR => '000042000000' AND AUFK-AUFNR <= '000042999999'.
    CASE PBW.
      WHEN 'DL'.
        LOMZ = 'DL'.
      WHEN OTHERS.
        LOMZ = 'LOMZ'.
    ENDCASE.
  ENDIF.
ENDIF.

Dieses Zusatzfeld hat nun für die Beispielnummernkreise 32000000 bis 32999999 und 42000000 bis 42999999 eine Überprüfung, ob es sich dabei um LOMZ Drittmittel oder nur DL für Dienstleistungsprojekte handelt. Die in anderen Nummernkreise abgebildeten Projekte sind keine Drittmittel auf die die LOMZ Definition angewandt wird und erhalten daher auch keinen Wert im Zusatzfeld LOMZ (das Feld bleibt daher leer).
 

Weiterentwicklung Query oder Recherchebericht zur Drittmittelstatistik

Ergänzend zur LOMZ Definition können nun natürlich auch noch die Mittelgeber der jeweiligen Projekte über den Finanzierungszweck identifiziert werden. Gerade für ein zentrales Berichtswesen kann hier eine Gruppierung der einzelnen Finanzierungszwecke, so als Beispiel die einzelnen EU Förderprogramme, zu Gruppen erfolgen, oder eben einfach der Finanzierungszweck ebenfalls mit ausgegeben werden. 

Diese Methodik ist im Artikel "Gruppierung von Finanzierungszwecken bei Drittmittelprojekten per Zusatzfeldcoding mit IF oder CASE" erläutert worden.

In Kombination mit einen Recherchebericht oder auch direkt einer Einzelpostenliste als SAP Query, wie im Artikel "Query Einzelpostenliste Innenauftrag mit Ausweis Ertrag und Aufwand Zweiter Teil Query zur Datenaufbereitung" kann nun relativ ohne Probleme eine entsprechende Auswertung der Drittmittelstatistik erfolgen. Denkbar wäre auch eine Saldenliste basierend auf der logischen Datenbank FMF in der die Summen je Finanzposition auf Kontierungsobjekt FOND und Finanzstelle ausgewertet werden können. Diese logische Datenbank habe ich bisher für die Auswertung von "Einzelposten Klassische Budgetierung Hierarchiebelge" verwendet denkbar ist hier aber auch die Summensätze der Tabelle FMTOX "Summensätze: Obligo und Ist   - Erweitert" in der die Summen je Kontierungsobjekt festgehalten sind. Hier hat ein Kollege einen recht praktischen Extrakt der Summensaldenliste je Finanzposition auf Ebene der Fonds entworfen. Ein Nachteil ist hier nur noch, dass zur Darstellung von Ertrag und Aufwand das Ergebnis erneut summiert werden muss. Jedoch ist dieses über lokale Felder oder Zusatzfelder die die Finanzpositionen gemäß Industriekontenrahmen (Kontenplan) beginnend mit 5*als Ertrag und 6* als Aufwand zuordnen können.

Sind die Berichte fertig erstellt können diese auch per Serienmail versandt werden. Bisher nutzte ich nur die Serienmailfunktion in Winword zum Versand von Serienmails (siehe Artikel "Serienmails über Serienbrieffunktion in Winword per Outlook, Thunderbird oder anderen Mailprogramm versenden") auf Facebook (siehe Beitrag vom 22.10.2016) bin ich jedoch auf zwei Methoden getroffen durch die entweder durch Plugin im Mailer Thunderbrid oder per VBA mit Outlook auch Dateianhänge wie ein Finanzbericht automatisch per Serienmail versandt werden können, so dass diese Berichte nicht zum Beispiel im SAP Business Work Place (siehe Artikel "SBWP: Berechtigungen Allgemeine Ablage") abgelegt werden müssen sondern auch direkt an die Finanzberichtsempfänger versandt werden können.

Innerhalb Excel sind dann natürlich auch graphische Analysen, wie im Artikel "Datentrends für Drittmittelstatistik mit Sparklines ab Excel 2010 darstellen durch Liniendiagramme in Zellen" beschrieben möglich. Wobei dieser Artikel gleichzeitig neben Sparklines auch verschiedene andere Auswertungsmöglichkeiten per Excel darstellt wodurch auch auf einen Blick die Bedeutung der einzelnen Daten hervorgehoben werden können.
 

Im Buch »Berichtswesen im SAP®-Controlling« bin ich ausführlich auf dies Thema Berichtswesen mit einen Schwerpunkt auf SAP eingegangen.
  Vielleicht finden sich hier ja auch noch weitere Anregungen für den Aufbau eines Berichtswesen mit SAP nicht nur für CO im Buch.
 

---

Hinweis:

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

---

Neben der Nutzung des Finanzierungszwecks im SAP Modul PSM-FM der entsprechende Fonds zusammenfasst (siehe hierzu Artikel "PSM-FM Grundlagen Finanzierungszweck im Haushaltsmanagement bei Recherchebericht und Selektion") wird im SAP Modul CO ein sprechender Schlüssel für CO Innenaufträge verwendet um hier anhand eines Zahlenintervalls eine Zuordnung zu bestimmten "Projektbereichen" zuzuordnen.

Sprechender Nummernkreis für CO Innenaufträge

Auch wenn die Verwendung von sprechenden Nummern nicht unumstritten ist (eine entsprechende Diskussion zu diesen Thema findet sich auch im Buch "Schnelleinstieg ins SAP Controlling (CO)" wo sowohl Vorteile als auch Nachteile einer Verwendung von sprechenden Nummern dargestellt werden. Wesentlicher Punkt war hier, dass Auftragsnummern im Nachhinein im Gegensatz zu anderen Stammdaten nicht verändert werden können und hier ein anfangs großzügig vorgesehener Nummernkreis nach einigen jahren eventuell aufgebraucht ist.

Auf diese Diskussion gehe ich nun aber nicht weiter ein sondern nehme bestehende Nummernkreisintervalle und Zuordnung zu Bereichen als gegeben hin und möchte nun in einer Query klären in welchen Bereich ein CO Innenauftrag zuzuordnen ist.

Prüfung ob eine Auftragsnummer innerhalb eines Nummernintervall liegt

Innerhalb von Excel kann dieses, wie im Artikel "Prüfung inwieweit ein Wert, bspw. eine Kostenstelle, innerhalb eines Intrevalls (Gruppe) liegt in Excel" beschrieben" durch eine VERWEIS Funktion realisiert werden. Auch Stammdatengruppen, sogenannte Sets können über eine Query (siehe Artikel "Auflösen von Stammdatengruppen nach Einzelwerten - Einzelwerte zu Sets") durch die Verknüpfung zweier Auswertungen zugeordnet werden.

Eine erheblich elegantere Möglichkeit ist es aber in einer Stammdatenauswertung vergleichbar zur Gruppierung von FINANZIERUNGSZWECK auch die Innenauftragsnummernintervalle entsprechend einer Gruppe virtuell zuzuordnen.

Coding von Zusatzfeld für Gruppierungen

Im Artikel "Gruppierung von Finanzierungszwecken bei Drittmittelprojekten per Zusatzfeldcoding mit IF oder CASE" wurde ja schon die Zuweisung von einzelnen Werten je Fall (CASE) mit mehreren Bedingungen (OR) dargestellt, so dass einzelne Finanzierungszwecke zusammengefasst werden konnten. Als Beispiel waren hier die unterschiedlichen EU Rahmenprogramme und die Zuordnung zu EU Mitteln erwähnt.

Einen ähnlichen Fall wurde schon im Abschnitt "Zusatzfeld VLE zur Darstellung virtueller Lehreinheit aus Teilstring der verantwortlichen Kostenstelle sofern nicht in einen anderen Feld ein Wert steht" des Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" beschrieben.

Die Ermittlung der VLE im Infoset anstatt in der Query per lokale Zusatzfelder wie im Artikel "Query über verantwortliche Kostenstelle des Innenauftrag - Bestimmung der Lehreinheit im Fachbereich durch Teil der Kostenstellennummer" hat den enormen Vorteil, dass hier alle Query die auf dieses Infoset aufbauen auch die Angabe des Bereichs oder die VLE auswerten können ohne selbst in der Query mühsam Felder zu basteln.

Analog zur Excellösung werden hier die vorrangestellten Nullstellen durch NO-ZERO entfernt, so dass danach ein Größenvergleich durchgeührt werden kann. Dabei gehe ich davon aus, dass die Innenauftragsnummern tatsächlich numerisch sind. Andernfalls muss man sich mit der Reihenfolge von alphanumerischen Intervallen beschäftigen.

ABAP: Enthält Variable nur Zahlenwerte

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

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

Ein ausführliches Beispiel wäre

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

IF L_innenauftrag CO L_ZAHLEN.
* Reine Auftragsnummer

ELSEIF.
* Alphanumerischer Innenauftrag

ENDIF.

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

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

Damit kann nun mit den vorhandenen Zahlenwerten weitergearbeitet werden.
Sollten auch Nachkommastellen oder Leerzeichen in Ordnung sein, muss der Vergleichsoperator um . und Leerzeichen erweitert werden. Allerdings sind dann neben Währungen oder Zahlen mit Nachkommastellen auch IP Adressen gültig. Als Beispiel ist hier der allzeits beliebte Public DNS (Domain Name System) von Google wie 8.8.8.8 oder 8.8.4.4 gültig. Sollte damit später gerechnet werden, ist das natürlich wesentlich schwieriger jedoch würde es 100 % in das Vergleichsmuster passen.Zugegeben diese Lösung ist nicht so elegant wie die Funktion ISNUMERIC innerhalb VBA (siehe Abschnitt "Negativzeichen hinter Zahlenwert" im Artikel "Office Integration - Excelansicht in SAP und Daten kopieren nach Excel", aber im Ergebnis liefert es in diesen Fall den gewünschten Effekt.
 

ABAP Prüfung ob Auftragsnummer innerhalb Nummernintervall

Nachdem mit oberen Coding geprüft worden ist, ob es sich bei der Auftragsnummer um eine Zahl handelt kann nun eine Prüfung erfolgen, inwieweit ein Innenauftrag innerhalb eines bestimmten Intervalls liegt und hierzu ein entsprechender Hinweis gegeben werden.

Ausgangspunkt ist das Tabellenfeld AUFK-AUFNR mit insgesamt 12 Zeichen. Hierbei sind die Auftragsnummern, sofern sie nicht 12 Zahlen umfassen mit führenden 0 abgespeichert. Nun besteht entweder die Möglichkeit eine Hilfsvariable zu definieren und über die Anweisung:

DATA: L_Innenauftrag TYPE C LENGTH 8.
WRITE AUFK-AUFNR TO L_INNENAUFTRAG NO-ZERO .

ohne führenden 0 als ein achtstelligen Wert in die lokale Variable L_Innenauftrag zu speichern. Dieses hat dann aber den Nachteil, dass sofern wir einen mehrstelligen Nummernkreis anlegen diese ebenfalls angepasst werden muss.

Daher ist es eleganter die führenden 0000 bei achtstelligen Innenauftragsnummern im Coding ebenfalls zu berücksichtigen.

Hierzu kann in der Definition des Infoset über die Schaltfläche ZUSÄTZE ein Zusatzfeld im Infoset angelegt werden.

In unseren Beispiel hat dieses folgende Eigenschaften:
Name: ZCOKEY
Langtext / Überschrift: ZCOKEY

Dieses hat den Vorteil, dass wir uns beim Coding leichter den Namen merken können (im Zusatzfeldcoding wird anhand des Namen der Wert zugewiesen.

Als Format bekommt das Feld TYP C (für Character) und eine Länge sowie Ausgabenlänge von jeweils 035 Zeichen.

Damit ist das Feld angelegt und es kann über die Schaltfläche CODING ZUM ZUSATZFELD ein entsprechendes Coding angelegt werden. Da wir nur numerische Innenauftragsnummern verwenden ist die im oberen Abschnitt erwähnte Prüfung ob es sich bei der Auftragsnummer um eine numerische Nummer handelt eigentlich obsolet, dennoch habe ich diese als äußere Klammer im Coding eingefügt.
 

WICHTIG / Nachtrag: CLEAR ZCOKEY

Es sollte darauf geachtet werden, dass die Variabele ZCOKEY durch die ABAP Anweisung CLEAR erst einmal geleert wird. Andernfalls merkt sich die Query bei mehreren Innenaufträgen den vorherigen Wert, sofern kein neuer Wert zugewiesen wird. Durch die Anweisung CLEAR wird die Variable bzw. das Zusatzfeld auf Initialwert zurückgesetzt. Sofern dieses nicht der Fall ist wundert man sich über die Ergebnisse.

Als einfaches Beispiel werden Buchprojekte auf Innenaufträgen abgebildet. Dabei sind Publikationen zu Office Produkten im Nummernkreis 4021*, SAP Literatur 4022* und BWL Bücher unter 4023* angelegt worden.

CLEAR ZCOKEY.
IF AUFK-AUFNR CO  '1234567890'.

IF AUFK-AUFNR     => '000040210000' AND AUFK-AUFNR <= '000040219999'.
  ZCOKEY = 'Office Literatur'.
ELSEIF AUFK-AUFNR => '000040220000' AND AUFK-AUFNR <= '000040229999'.
  ZCOKEY = 'SAP Literatur'.
ELSEIF AUFK-AUFNR => '000040230000' AND AUFK-AUFNR <= '000040239999'.
  ZCOKEY = 'BWL Literatur'.
ENDIF.

ENDIF.

Natürlich ist dieses wesentlich einfacher durch Zuordnung von Profit-Centern wie die vorhandenen Profit-Center OFFICE, SAP, BWL möglich. Im Hochschulbereich könnten das Profit-Center für Landesmittel (L), Drittmittel (D) und Sondermittel (S) sein.

Endziffer Innenauftrag zusätzlich zum Nummernkreisintervall prüfen

Soll nun aber zusätzlich noch unterschieden werden, ob es hier ein gedrucktes Buch ist, eine elektronische Publikation oder die Vorbereitung auf ein Buch und dieses durch die letzte Endziffer des Innenauftrages festgelegt werden kann die IF Anweisung noch um eine weitere Bedingung erweitert werden. Die Endziffer 0 ist dabei für normale Buchprojekte, die Endziffer 1 für Print und 2 für Ebook.

CLEAR ZCOKEY.
IF AUFK-AUFNR CO  '1234567890'.

IF AUFK-AUFNR     => '000040210000' AND AUFK-AUFNR <= '000040219999' AND AUFK-AUFNR+11(1) = '0'.
  ZCOKEY = 'Office Literatur'.
ELSEIF AUFK-AUFNR => '000040210000' AND AUFK-AUFNR <= '000040219999' AND AUFK-AUFNR+11(1) = '1'.
  ZCOKEY = 'Office Literatur PRINT'.
ELSEIF AUFK-AUFNR => '000040210000' AND AUFK-AUFNR <= '000040219999' AND AUFK-AUFNR+11(1) = '2'.
  ZCOKEY = 'Office Literatur Ebook'.

...

ENDIF.

ENDIF.

Durch die Offset Anweisung AUFK-AUFNR+11(1) wird das letzte Zeichen der 12 Stelligen Innenauftragsnummer des Tabellenfeld AUFNR der Tabelle AUFK verwendet.Durch die optionalen Angaben eines Offsets +<o> und eine Länge (<l>) direkt hinter dem Feldnamen <f>, wird der Teil des Felds, der auf Position <o>+1 beginnt und die Länge <l> hat, als eigenes Datenobjekt angesprochen. Diese Möglichkeit haben wir auch im Feld ZAUFNR für den Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" verwendet um PSM Fonds mit CO innenaufträgen zu verknüpfen.

ACHTUNG: Sobald die IF Bedingung erfüllt ist werden keine weiteren Bedingungen geprüft, daher ist hier entsprechende Sorgfalt zu walten.

Weitere Bestandteile der Innenaufragsnummer als Bedingung prüfen

Entsprechend oberen Codingbeispiel ist es natürlich auch möglich weitere Bestandteile der Innenauftragsnummer als Prüfmerkmal zu verwenden. Insgesamt wären hier acht Bedingungen möglich. Ein anderes Beispiel zu Print und Ebook wären bei Gebäudeinnenaufträgen eine Unterscheidung nach Bewirtschaftung und Bauunterhaltung :-) Vielleicht haben Sie dann noch einen dreistelligen Standort oder eine Organisationseinheit (zum Beispiel einen Fachbereich) innerhalb ihrer sprechenden Auftragsnummer verschlüsselt und wollen diese auflösen.

Nummernintervall und Bestandteile der Innenauftragsnummer (hier: Endziffer) per IF und CASE überprüfen

Nehmen wir hierzu wieder das Intervall der SAP Bücher als Beispiel und betrachten folgendes schöne Coding

CLEAR ZCOKEY.
IF AUFK-AUFNR CO  '1234567890'.

IF AUFK-AUFNR     => '000040210000' AND AUFK-AUFNR <= '000040219999'.
  ZCOKEY = 'Office Literatur'.
ELSEIF AUFK-AUFNR => '000040220000' AND AUFK-AUFNR <= '000040229999'.
  ZCOKEY = 'SAP Literatur'.
ENDIF.

IF AUFK-AUFNR => '000040220000' AND AUFK-AUFNR <= '000040229999'.
    CASE AUFK-AUFNR+11(1).
WHEN '1'.
     ZCOKEY = 'SAP Literatur PRINT'.
WHEN '2'.
    ZCOKEY = 'SAP Literatur EBOOK'.
ENDCASE.
ENDIF.

ENDIF.

Im ersten Absatz des Coding werden nur Nummern behandelt und alphanumerische Innenaufträge ignoriert. Danach werden anhand des Nummernintervalls das Genre (hier SAP Literatur) festgelegt. Danach wird für die Bücher (hier nur das Intervall SAP Literatur) die Endziffer als Argument in der CASE Anweisung übergeben und die verschiedenen Zustände per WHEN ausgewertet.

Ein klein wenig eleganter (da für alle Publikationen) ist das natürlich mit CONCATENATE  womit zwei Strings miteinander verbunden werden.

Im Beispiel wären dieses der String 'Ebook' oder 'Print' mit den vorher festgelegten Genre (welches in der Variable COKEY schon über die IF Schleife festgelegt wurde.

Konkret wäre hier also der Abschnitt wie folgt anzupassen.

IF AUFK-AUFNR => '000040210000' AND AUFK-AUFNR <= '000040239999'.
CASE AUFK-AUFNR+11(1).
WHEN '1'.
CONCENTATE ZCOKEY ' Print' INTO COKEY RESPECTING BLANKS.
WHEN '2'.
CONCENTATE ZCOKEY ' Ebook' INTO COKEY RESPECTING BLANKS.
ENDCASE.
ENDIF.

Die Abap Anweisung

    CONCATENATE altenstring neuenstring INTO altenstring REPSECTING BLANKS.

 verkettet getrennte Zeichenfolgen zu einer Zeichenfolge. Durch das Argument RESPECTING BLANKS wird auch das Leerzeichen vor der Art der Publikation ' Print' oder ' Ebook' berücksichtigt.
 

Alternative Profit-Center-Rechnung

Aus verschiedenen auch eingangs erwähnten Gründen haben wir uns gegen diese Vorgehensweise in unserem Buch entschieden und statt dessen Profit-Center genutzt um die einzelnen Publikationsfelder des im Buch erwähnten Verlages abzudecken.
  Paperback ISBN: 9783960126874

Für 19,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Ebook ISBN: 9783960120414

Sofern Sie aber eine wesentlich feingliedrigere Zuordnung von Innenauftragsnummern zu entsprechenden Nummernbereichen haben, kann hier eine wesentlich feingliedriger Unterscheidung der einzelnen Innenaufträge aus sprechenden Nummern bei extern vergegebenen Auftragsnummern hinterlegt werden. Gerade bei einer Vielzahl von Sondermitteln oder unterschiedlichen Landesmitteln die nur anhand der Nummer unterschieden werden kann es hier für neue Kolleginnen und Kollegen eine Hilfe sein, wenn diese hier eine kurze Erläuterung erhalten um was für eine Art von Projekten es sich dabei handelt.

Verwendung Zustazfeld COKEY für Projektbereich in Query

Sofern nun also das Zusatzfeld in eine Feldgruppe übernommen worden ist besteht auch die Möglichkeit in einer Query auf diese Bezug zu nehmen. Im Ergebnis kann somit die im Artikel "Query Einzelpostenliste Innenauftrag mit Ausweis Ertrag und Aufwand Zweiter Teil Query zur Datenaufbereitung" vorgestellt Query um weitere Informationen wie auch die FINGRUPPE erweitert werden.

Sofern zu einzelnen Innenaufträgen auch die Mittelherkunft anhand eines Ordnungsbegriffes klar definiert ist (siehe "FI-AA Anlagenbuchhaltung: Klassifizierung von Anlagen") kann in einer Quey auch die korrekte Zuordnung von Ordnungsbegriff und Innenauftragsnummernbeeich verglichen werden. Hierzu verweise ich gerne auf den Artikel "Zusammenfassung Query über Anlagenzugang - Auswertung Investitionen aus Profit-Center-Rechnung", aber dieses ist dann auch wieder ein anderes teils auch komplexeres Thema. Grundsätzlich sind aber mit SAP Query nicht nur Stammdatenauswertungen, Analysen und die Darstellung von Bewegungsdaten möglich sondern auch eine Unmenge an Kombination aus vorhandenen Daten und sogar die Neuinterpretation von im System vorhandenen Daten, so dass eine Menge an bisher in Excel erfolgte Schritte nun sozusagen einen Schritt vorverlagert nach SAP gemacht werden können.

---

Hinweis:

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

---

Das Thema "Finanzierungszweck" innerhalb des SAP Modul Public Sector Management - Haushaltsmanagement (PSM-FM) ist bisher in der Hauptsache Thema bei der Erstellung von Stammdatenlisten für Fonds gewesen. Hier 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" beziehungsweise in den Artikeln "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" und "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck oder auch Status GESPERRT bei Innenaufträgen" dieses relativ ausführlich erläutert.

Darstellung Finanzierungszweck im Recherchebericht

Aus Sicht einer Anwendenden ist es aber oftmals so, dass nicht eine Stammdatenliste sondern ein Bericht für diverse Projekte hier hilfreich ist. Natürlich kann innerhalb eines erstellten Rechercheberichtes (siehe "Saldenliste für Fonds im Haushaltsmanagement Saldo gegen Ertrag und Saldo gegen Budget") anhand des Würfelmodells bei der Auswertung von der Darstellung der Fonds auf Finanzierungszwecke gewechselt werden.

Unter den Punkt Navigation ist ein Vorrat der verfügbaren Merkmale des Berichts vorhanden. Hier kann nun der Finanzierungszweck mit einfachen Klick markiert werden und per Klick auf die Schlüsselspalte die Darstellung von Fonds auf Finanzierungszwecke gewechselt werden. Sofern Sie nun ein Merkmal wie einen bestimmten Finanzierungszweck doppelt klicken wird dieses als Merkmalsfilter  gesetzt und es werden alle Fonds zu diesen Merkmal dargestellt Sofern Sie hier die Merkmalsdarstellung erneut auf Fonds umstellen oder alternativ auch die Fonds per Doppelklick als Filter verwenden um dann die Buchungskonten auf Ebene der Finanzpositionen dargestellt zu bekommen.

Es kann jedoch sein, dass Sie schon im Vorfeld nur Fonds eines bestimmten Finanzierungszweck auswerten wollen. Dazu können Sie im Einstiegsbild des Rechercheberichtes auf die Wertauswahlhilfe (F4 Taste) gehen und erhalten eine Suchhilfe über die Fonds. Im Reiter "Suche über Attribute" ist es dann möglich über die Fondsart oder eben auch Finanzierungszweck schon die relevanten Fonds auszuwählen.

Hintergrund: Finanzierungszweck als Stammdatum im Modul PSM-FM

Nebenbei handelt es sich beim Finanzierungszweck um ein Stammdatum, dass Sie in der Stammdatenpflege des Fonds unter

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

in der Stammdatenpflege (Transaktion FM5I für Anlegen oder FM5U für Ändern) im Abschnitt Zusatzdaten über das Feld Finanzierungszweck auswählen können. Hier sind alle im System schon angelegte Finanzierungszwecke zur Auswahl vorhanden.

Sofern Sie weitere Finanzierungszwecke benötigen besteht die Möglichkiet diese ebenfalls als Stammdatum mit Bezeichnung und Beschreibung anzulegen.

Diese werden ebenfalls innerhalb des Finanzkreises angelegt. Sie finden die Funktion unter:

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

und hier mit der Transaktion FM6I zum Anlegen, FM6U zum Ändern und FM6S zum Anzeigen.

Gerade beim Stammdatenverzeichnis (Transaktion S_KI4_38000039 - Verzeichnis der Fonds) ist die Verwendung eines Finanzierungszwecks sehr praktisch. Nebenbei gerade im Zusammenhang mit Rechercheberichten dürfte auch der Artikel "Frühjahrsputz oder geschützte Varianten und nicht mehr benötigte Rechercheberichte entfernen oder reorganisieren" bei der Pflege eines aktiven Berichtswesen sinnvoll.

Exkurs nach CO

Neben den einzelnen Merkmalen im Haushaltsamangement (Modul PSM - Public Sector Management / Komponente FM - Funds management) in der öffentlichen Verwaltung kann hier auch das Controlling eine spannende Komponente sein.

Hier verweise ich gerne auf den Artikel "CO Objekte indirekt auswerten Teil 2/2 hier: Innenauftrag zum Fond WIPLAN" als weiteren Beleg für ein integratives System. wo sich gerade im Rechnungswesen auch die ein oder andere überraschende Überschneidung finden lässt.

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.

---

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

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

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

Phasen eines Auftrag bzw. Status

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

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

• AUFK-PHAS0 -  Phase 'Auftrag eröffnet'
• AUFK-PHAS1 -  Phase 'Auftrag freigegeben'
• AUFK-PHAS2 -  Phase 'Auftrag technisch abgeschlossen'
• AUFK-PHAS3 -  Phase 'Auftrag abgeschlossen'

Entsprechend bauen auch diese Phasen aufeinander auf und lassen entsprechend immer weniger Vorgänge zu.

  Daneben sind die einzelnen Datumsfelder wie folgt in der Tabelle AUFK hinterlegt:

• AUFK-IDAT1 - Freigabedatum
• AUFK-IDAT2 - Technisches Abschlußdatum
• AUFK-IDAT3 - Abschlußdatum

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

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

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

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

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

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

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

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

Auswertung Query über einzelne Phasen eines Projektes

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

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

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

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

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

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

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

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

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

Die drei Zusatzfelder sind in den folgenden Abschnitten

• "Zusatzfeld VLE zur Darstellung virtueller Lehreinheit aus Teilstring der verantwortlichen Kostenstelle sofern nicht in einen anderen Feld ein Wert steht"
• "Zusatzfeld Gesperrt (Sperrkenzeichen auswerten)"
• "Zusatzfeld ZAUFNR um die Stammdatentabelle FMFINCODE als Zusatztabelle im Infoset einzufügen"

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

Reihenfolge Selektionsfelder festlegen

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

Konzeption Prozesse und notwendige Stammdatenfelder

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

 

---

Hinweis:

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

---

Ich hatte vor einiger Zeit schon einmal eine Query beschrieben die relativ komfortabel eine Alternative zur Transaktion KOSRLIST_OR Abrechnungsvorschriften  darstellt, allerdings sind im Laufe der Zeit noch weitere Aspekte beziehungsweise Anforderungen in Richtung einer automatischen Kontrolle dieser Abrechnungsvorschrift hinzugekommen. Auf diese Anforderungen und die Systematik der Auftragsabrechnung möchte ich im folgenden Artikel ausführlicher eingehen.
 

Abrechnungsvorschrift Auswertung über KOSRLIST_OR

Die normale Auswertung der Abrechnungsvorschriften ist im SAP Menü unter

• Rechhnungswesen->
• Controlling->
• Innenaufräge->
• Infosystem->
• Berichte zu Innenaufträgen->
• Stammdatenverzeichnis->
• Abrechnungsvorschriften (Transaktion KOSRLIST_OR )

zu finden.

Allerdings hat diese Auswertung den Nachteil, dass hier keine ALV (sprich Liste) erstellt wird sondern in einer Überschriftzeile der Innenauftrag als Kopfzeile dargestellt wird und unten drunter die Abrechnungsvorschriften als einzelne Positionen dargestellt werden.

Sollte, aus Gründen, nun ein Vergleich oder gar Export der Abrechnungsvorschriften erfolgen ist dieses etwas problematisch.

Von einigen Kolleginnen und Kollegen wurde ich angesprochen, ob nicht eine Kontrolle der Abrechnungsvorschriften nicht auch über eine Query möglich ist. Bisher wurde dieses relativ aufwändig in Excel erledigt.

Besonders bei der Abrechnung von Kosten auf Kostenstellen soll hier überprüft werden, ob die empfangende Kostenstelle identisch zur verantwortlichen Kostenstelle des Innenauftrages ist.

Hintergrund: Abrechnung von Landesmittelprojekten

In der Regel hängen die einzelne Projekte an einer Kostenstelle einer Professur / eines Institut oder einer Einrichtung und sollen im Rahmen der Auftragsabrechnung für eine Plankostenumlage auf die jeweiligen Kostenstellen umgelegt werden. Auf die unterschiedlichen Möglichkeiten der Auftragsabrechnung gehe ich etwas später in diesen Artikel ein.

Nun möchte ich kurz die Möglichkeit einer Query zur Auswertung der Abrechnungsvorschriften vorstellen und diese um eine Prüffunktion erweitern.
 

Infoset zur Auswertung Auftragsabrechnung

Technisch betrachtet beruht das Infoset aus den beiden Tabellen AUFK für die Stammdaten der Innenaufträge und COBRB für die Aufteilungsregeln Abrechnungsvorschrift Auftragsabrechnung.

Die beiden Tabellen sind über das Tabellenfeld OBJEKTNUMMER der beiden Tabellen aufgebaut. Hier werden also die beiden Felder AUFK-OBJNR und COBRB-OBJNR miteinander verknüpft und alle Tabellenfelder in das Infoset übernommen.

Query zur Darstellung Abrechnungsvorschrift

Die Query ist dabei wie im Artikel "Query Abrechnungsvorschriften Innenauftrag" umfassender beschrieben wie folgt aufgebaut:

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

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

Die im ursprünglichen Artikel beschrieben weiteren Felder zu den Stammdaten Kostenstelle etc. habe ich nun einmal außen vor gelassen.

Soweit ist diese Query auch schon bekannt. Nun gab es allerdings eine Anfrage, dass die Aufteilungsregel der Innenaufträge automatisch überprüft werden sollten.

Ausgangslage unterschiedliche Abrechnungsvorschriften

Hintergrund ist, dass in der Abrechnungsvorschrift drei Einträge vorhanden sind.

• Abrechnung der Kosten auf eine Kostenstelle
  In der Abrechnungsvorschrift wird als Typ KST (Kostenstelle) und als Abrechnungsempfänger  eine Kostenstelle zugeordnet. Die Verteilung der einzelnen Kostenarten erfolgt über die Ursprungszuordnung ZUK werden die einzelnen Kostenarten entsprechenden Abrechnungskostenarten zugeordnet.
• Abrechnung Erlöse auf Erlösauftrag
  Hier ist die Abrechnungsvorschrift so gepflegt, dass als Typ AUF (Auftrag) und ein entsprechender Innenauftrag als Abrechnungsempfänger hinterlegt. Als Ursprungszuordnung wird hier ZUE hinterlegt.
• Abrechnung neutrales Ergebnis
  Neutrale Kosten-/Erlösarten werden ebenfalls per Typ AUF (Auftrag) auf einen Innenauftrag zum neutralen Innenauftrag gelegt werden. Hier wird als Ursprungszuordnung ZUN festgelegt.

Hintergrund: Customizing Abrechnungsvorschrift

Das Customizing der Arbrechnungsvorschriften ist in der Transaktion SPRO unterhalb

• Controlling->
• Innenaufträge->
• Planung->
• Abrechnung pflegen

aufrufbar. Hier können zum einen die einzelnen Abrechnungsschema gepflegt werden aber auch das Ursprungsschema gepflegt werden. Dieses soll aber nicht Thema des Artikels sein.

Sofern Kosten auf eine Kostenstelle abgerechnet werden soll, sollte diese Kostenstelle der verantwortlichen Kostenstelle des Innenauftrages entsprechend. Gerade wenn hier in der Abrechnungsvorschrift eine Abweichung vorhanden ist, kann dieses eine sehr ausführliche Fehlersuche nach sich ziehen.

Lokales Feld mit Ikone LED anlegen

Hierzu arbeiten wir in der Query wieder einmal mit lokalen Feldern.

Um lokale Felder zu definieren wird nicht direkt die Grundliste der Query bearbeitet (wo auch das Layoutdesign gepflegt wird) sondern innerhalb der Querypflege (Transaktion SQ01) mit "nächstes Bild (F6)" auf die Feldauswahl der Query gewechselt. Alternativ ist es auch möglich dies über das Menü SPRINGEN->FELDAUSWAHL->FELDAUSWAHL zu erreichen.

Über
BEARBEITEN->KURZBEZEICHNUNG
kann für die einzelnen Felder eine Kurzbezeichnung eingestellt werden. Nun werden rechts neben den Datenfeldern Eingabefelder für die Kurzbezeichnung angegeben. Hier erhalten nun folgende Felder eine Kurzbezeichnung (in der Beschreibung ist die Bezeichnung, gefolgt von der angelegten Kurzbezeichnung (fett hervorgehoben) und des dahinter technisch liegenden Tabellenfeldes angegeben):

Auftragsstammdaten
Verantwortliche Kostenstelle VKOST  (AUFK-KOSTV)
Aufteilungsregeln Abrechnungsvorschrift Auftragsabrechnung
Ursprungszuordnung URZUO (COBRB-URZUO)
Kontierungstyp KONTY (COBRB-KONTY)
Empfangende Kostenstelle EKOST (COBRB-KOSTL)

Diese Kurzbezeichnung ist notwendig, da wir auf diese dann Bezug nehmen, wenn wir ein eigens Feld mit einer Formel anlegen.

Dieses geht über

BEARBEITEN->LOKALES FELD->ANLEGEN

Dieses Lokale Feld wird dann in der Feldgruppe angelegt, in der wir uns gerade befinden. Von daher ist es ganz praktisch, dass wir uns in den Abrechnungsvorschriften befinden.

Hierzu legen wir ein Feld mit folgenden Eigenschaften an:

lokales Feld (CHKABRV)
Kurzbezeichnung:  CHKABRV
Feldbezeichnung: CHKABRV
Überschrift: CHKABRV
Eigenschaften:
Ikone
Berechnungsvorschrift:
Hier wird eine komplexe Berechnung mit folgenden Bedingungen hinterlegt:

Bedingung: VKOST = EKOST AND URZUO = 'ZUK' AND KONTY = 'KS'
Formel: ICON_LED_GREEN

Bedingung: VKOST <> EKOST AND URZUO ='ZUK' AND KONTY = 'KS'
Formel ICON_LED_RED

Sonst lassen wir leer.

Die Bedingung ist ein klein wenig tricky.

Als erstes wird geprüft ob die Verantwortliche Kostenstelle des Innenauftrags und das Feld empfangende Kostenstelle (COBRB-KOSTL) identisch sind oder ob es hier Abweichung gibt

In der ersten Bedingung sollten die übereinstimmen (dank = ) und in der zweiten gibt es eine Abweichung ( <>  bedeutet ungleich).

Daneben werden aber auch folgende Fragestellungen berücksichtigt

Werden tatsächlich Kosten verteilt und nicht etwa Erlöse?
Wie erwähnt gibt es allerdings neben ZUK für die Verteilung der Kosten noch eine Verteilung von Erlöse auf entsprechende Erlösaufträge über die Ursprungszuordnung ZUE. Hier kann die Kostenstelle nicht übereinstimmen, da die Erlöse der Innnenaufträge auf entsprechende andere Innenaufträge (zum Beispiel Erlösaufträge der einzelnen Lehreinheiten) verteilt werden. Daher soll eine Kontrolle nur erfolgen, wenn es sich bei der Ursprungszuordnung um ZUK für die Kostenabrechnung handelt.

Ist der Abrechnungsempfänger vom Typ her eine Kostenstelle?
Problematisch sind nun Innenaufträge deren Kosten nicht auf Kostenstelle sondern auf einzelne Produkte (Drittmittel, Weiterbildung vergleichbares) abgrechnet werden. Hier ist der Abrechnungsempfänger dann keine Kostenstelle sondern ein Innenauftrag. Deswegen gibt es als dritte Bedingung die Kontrolle handelt es sich beim Typ um eine Kostenstelle "KS". Dieses wirkt nun iritierend, da wir bei der Pflege von Abrechnungsvorschriften im Innenauftrag ja immer eine KST angeben, wie auch in unseren Buch "Schnelleinstieg ins SAP Controlling (CO)" ausführlich erläutert wurde (siehe Buchempfehlung).
Dieses liegt daran, dass in der Abrechnungsvorschrift der Wert zwar als KST zugewiesen wird, in der Datenbank das Feld allerdings unkonventiert als KS gespeichert ist. Besonders ansprechend ist das in der Transaktion SE16H zu betrachten. Ferner umfasst das Feld KONTY der Tabelle COBRB auch nur zwei Zeichen.
Dieses ist auch der Grund, warum ich gerne Tabellendefinitionen (SE12) oder Tabellenanzeige (SE16H) für die Administration von Query nutze ansosnten wundert man sich, warum eine Auswertung nicht funktioniert.


Was für eine Ikone soll als Symbol ausgegeben werden (Formel)?
Als Formel wird nun der Wert der IKONE angegeben.

Hier nutze ich sehr gerne LED Icons die je nach Zustand (Ergebnis) RED = Fehler, YELLOW = Kontrolle erfoderlich oder GREEN = Alles okay ein Ergebnis liefern.

Gemäß SAP Design Guide (siehe https://experience.sap.com/files/guidelines/icons_sap/index.htm ) hätte ich hier wohl ebenfalls besser ICON_CHECKED (grüner Haken) , ICON_INCOMPLETE (rotes Kreuz) oder ICON_FAILURE (Warnhinweis) verwenden können.

Die LED Icons  ICON_LED_GREEN (Green LED; go; correct), ICON_LED_RED (Red LED; stop; incorrect) erscheinen mir hier allerdings tatsächlich als wesentlich sinnvoller.

Wenn ich nun dieses Feld ebenfalls in meine Grundliste übernehme erhalte ich bei gepflegten Abrechnungsvorschriften direkt eine LED wenn es eine entsprechende Abweichung gibt und kann sogar nach Fehlern filtern.

Handhabung der Query

Nachdem die Query angelegt ist lohnt es sich abzurechende Projekte vorab per Query auszuwerten und in der Anzeige beziehungsweise einer Layoutvariante nach roten LEDs zu filtern. Auf diese Weise ist es möglich schon vor der Abrechnung etwaige Abweichungen zu identifizieren und zu verhindern. Ferner kann dieses auch hilfreich sein, entsprechende Abweichungen bei Kostenumlage (zum Beispiel durch die Plankostenumlage) zu korrigieren. Mit ein wenig Glück muss man dann nicht alle Zyklen stornieren (oder eine erneute Plankopie anfertigen) sondern kann dann in Höhe der Abweichung eine Plankorrektur vornehmen. Sofern eine Umlage im Ist erfolgt, kann hier auch das Thema "Segmentkorrektur in SAP" interessant sein.

Nebenbei beim Thema Umlagezyklen oder generell der kennzahlenbasierten Verrechnung sind auch die Artikel "Innenaufträge als Empfänger von Umlagezyklen (KSUB)" oder die Analyse von Kostenumlagen wie im Artikel "ReportWriter: Ergebnisse Planumlage (KSUB) je Partnerobjekt"  oder "Auswertung Statistische Kennzahlen auf Innenaufträge für Lehrimport und Lehrexport auf Ebene Studiengänge". Gerade im Controlling bietet sich hier aber neben der Query auch Report Writer beziehungsweise Report Painter als Analysewerkzeug an. Nach Möglichkeiten sollten aber Auswertungen, wie die hier beschriebene Überprüfung der Abrechnungsvorschrift genutzt werden um die doch sehr umfangreiche Suche nach Abrechnungsfehlern zu vermeiden.

Gerade bei einer Analyse von Einzelbelegen im Plan, wie im Artikel "CO Planeinzelposten Objekt und Partnerobjekt auswerten / Mehrere Felder summieren" beschrieben ist enorm aufwändig.

 

---

Hinweis:

Eine kurze Einführung in das Thema SAP Query habe ich im Artikel
"Grundlagen Kurzeinführung und Handbuch SAP Query" beschrieben und hoffe Ihnen hier eine Einführung ins Thema bieten zu können. Wie erwähnt kann im Controlling auch das Thema "Grundlagen Kurzeinführung und Handbuch Report Painter Report Writer" sehr nützlich sein.

---

Eine spannende Möglichkeit zum separaten Ausweis von Kosten bieten im Controlling mit SAP die statistischen internen Innenaufträge. Daher ist es auch nicht weiter verwunderlich, dass dieses Thema in einen Forenbeitrag aufgegriffen wurde und sich hier die Frage stellte wo nun eigentlich der Unterschied zwischen einen  echten interner Auftrag und einen statistischer interner Auftrag innerhalb SAP CO ist. Im folgenden Abschnitt sollen aber nicht nur die Unterschiede sondern auch Anwendungsgebiete für statistische Innenaufträge geschildert werden.
 

Unterschied statistischer und echten internen Auftrag

Ein statistischer Innenauftrag kann genutzt werden um Kosten, die eigentlich auf eine Kostenstelle laufen dann doch statistisch auf einzelne zusätzliche Kontierungsobjekte auswerten zu können.

Im Gegensatz dazu werden "echte" Innenaufträge genutzt um die Kosten / Erlöse für eine Maßnahme (Projekt) mit einer klaren Laufzeit zu sammeln. Hierdurch unterscheidet sich ein Innenauftrag schon von der auf Dauer ausgelegte Kostenstelle.
Der Vorteil von Innenaufträge ist dabei, dass die Innenaufträge sich nicht zwangsmäßig an der Unternehmensstruktur (wie z.B. Kostenstellen) orientieren müssen sondern auch temporär genutzt werden können um den Fokus auf die Frage des "Wofür?" sind entsprechende Kosten (und Erlöse) entstanden.
 

Anwendungsfall für statistischer Innenauftrag: Fuhrparkkosten

Ein Klassisches Beispiel für die Anwendung eines statistischen Innenauftrag ist bei der Verwaltung von Fuhrparkkosten.

Für jedes Fahrzeug wird ein statistischer Innenauftrag (z.B. mit Kurztext KFZ Kennzeichen) angelegt. Die Buchung der einzelnen Fahrzeuge (Tanken, Werkstatt, Versicherung, Steuer) landen nun sowohl auf die Kostenstelle des Fuhrparks als auch durch die Nebenkontierung auf den statistischen Innenauftrag (hierzu ist die echt bebuchte Kostenstelle in den Stammdaten des Innenauftrags hinterlegt).

Für Auswertungszwecke können nun die echten Kosten des gesamten Fuhrparks auf der Kostenstelle Fuhrpark ausgewertet werden, aber statistisch ist es ebenso möglich einzelne Innenaufträge je Fahrzeug auszuwerten.

Alternativ könnten hier auch einzelne Liegenschaften verwaltet werden, die als Gesamtkosten dann auf den Gebäudekostenstellen laufen.

Ein solches Verfahren kann Sinn machen, da die Kraftfahrzeuge  nach einiger Zeit ausgemustert werden, die Gesamtkosten des Fuhrparks aber auf Dauer bestehen bleiben.

Innerhalb des Auftragsstamm ist in der Registerkarte "Zuordnungen" wird auch bei normalen Innenaufträgen eine Zuordnung einer Kostenstelle in Form der verantwortlichen (teilweise auch anfordernden) Kostenstelle gepflegt. Dieses hat jedoch für die Buchung keine Auswirkung, da der Beleg "echt" auf das CO-Objekt Innenauftrag gebucht wird.

Keine Regel ohne Ausnahme, sofern PSM-FM im Einsatz ist wird die verantwortliche Kostenstelle für Budgetbelege genutzt.

Ferner ist in der Registerkarte Zuordnungen auch das Profit-Center zu pflegen. Oftmals sind die Profit-Center aber auch an den Kostenstellen angelegt und hier wird tatsächlich der Beleg auf das zugeordnete Profit-Center fortgeschrieben.

Festlegen statistischer Innenauftrag im Auftragsstamm

Für einen statistischen Innenauftrag ist nun aber die Registerkarte "Steuerung" entscheidend. Hier kann im Abschnitt Steuerung die Funktion "statistischer Auftrag" markiert kann im Feld "Echt bebuchte Kostenstelle" die zu bebuchende Kostenstelle hinterlegt.

Dieses Feld wird auch tatsächlich nur bei statistischen Innenaufträgen berücksichtigt.

Exkurs: Literaturhinweis zum SAP Controlling

Soweit wurde darauf auch im Buch "Schnelleinstieg ins SAP Controlling (CO)" (ISBN 9783960126874 ^*)  hingewiesen.

  Paperback ISBN: 9783960126874

Für 19,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Ebook ISBN: 9783960120414
 

Nachtrag:
Wie im Artikel "Nicht nur für Erbsenzähler 😉 - 2., erweiterte Auflage »Schnelleinstieg ins SAP® Controlling (CO)« " beschrieben ist mittlerweile eine 2. erweiterte Auflage unseres Schnelleinstieg ins SAP Controlling erschienen.
 

Schnelleinstieg ins SAP®-Controlling (CO) – 2., erweiterte Auflage

Eine ausführliche Beschreibung ist unter Buchempfehlungen unter  Schnelleinstieg ins SAP®-Controlling (CO) – 2., erweiterte Auflage (SAP Modul CO; interne Rechnungswesen) zu finden.

Autoren: Andreas Unkelbach, Martin Munzel

Verlag: Espresso Tutorials GmbH

2. Auflage (08. März 2019) Paperback ISBN: 9783960120346

Für 29,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Oder bei Amazon **

 

 

Hier möchte ich auch einen kleinen Hinweis auf das Update der SAP-Bibliothek-Flatrate hinweisen, in der natürlich ebenfalls dieses Buch enthalten ist.
  Werbung


Aber auch sonst ist die neue Oberfläche einen Blick wert. Nun möchte ich aber auf zwei weitere Anwendungen für statistische Innenaufträge eingehen. Zum Einen im Investitionsmanagement und zum anderen für die Nutzung der Verfügbarkeitskontrolle gegenüber gebuchten Budgets auf Kostenstellen, was normalerweise ohne Trickkiste nicht möglich ist.
 

Statistische Innenaufträge im Investitionsmanagement

Im Standard werden alle Buchungen auf den statistischen Auftrag zusätzlich, hier allerdings in echt, auf die hinterlegte Kostenstelle gebucht. Es besteht allerdings auch die Möglichkeit eine "abweichend einstellbare Buchungslogik" zu hinterlegen. Hier hilft dir die Feldhilfe zur "echt bebuchten Kostenstelle" weiter.

Im entsprechenden Beitrag kam es noch zu folgender Ergänzung seitens MrBojangles auf einen Anwendungsfall aus dem Investitionsmanagement.

Hier können statische Innenaufträge zur Darstellung von direkt aktivierten Anlagegütern (Investitionen) genutzt werden, die primär auf die Anlage und statistisch auf einen Innenauftrag gebucht werden. Der statistische Innenauftrag kann dann für die Budgetüberwachung genutzt werden.

Echte Innenaufträge würden verwendet werden, wenn erst die Kosten auf den Innenauftrag gesammelt werden um diese dann später auf die fertige Anlage abzurechnen. Allerdings wurde dieses im Forumbeitrag " Echter interner Auftrag vs. statistischer interner Auftrag" noch wesentlich schöner beschrieben.
 

CO Budgetierung und Verfügbarkeitskontrolle auf Kostenstellen

Im Bereich PSM-FM ist eine Verfügbarkeitskontrolle gegen Budget auf Ebene der Finanzstellen beziehungsweise Kostenstellen möglich. Innerhalb CO ist eine solche Verfügbarkeitskontrolle nur bei Projekten/Innenaufträgen gegen Budget möglich.

Hier gibt es einen entsprechenden Forumsbeitrag auf fico-forum.de "Budgetierung auf Periodenebene und auf Kostenstellen".

Allerdings kann über einen statistischen Innenauftrag die Verfügbarkeitskontrolle auch für Kostenstellen verwendet werden, auch wenn

Für eine Verfügbarkeitskontrolle auf Kostenstellen empfiehlt die SAP hier einen Umweg bzw. verweist in der Onlinehilfe noch auf eine alternative Möglichkeit in der zwar nicht gegen Kostenstellenetats aber indirekt gegen Budget im Modul CO eine Buchung geprüft werden kann. Ich fand die hier vorgestellte Lösung interessant und würde diese als kleine Ergänzung noch hier (für die nächste Suche danach) festhalten.

Über die OSS Trickkiste ist tatsächlich auch im CO eine aktive Verfügbarkeitskontrolle gegen Budget bei Kostenstellen indirekt möglich.Den entsprechenden Trick liefert hiebri der OSS Hinweis (SAP Note) "68366 - Aktive Verfügbarkeitskontrolle auf Kostenstellen" durch einen Umweg über einen statistischen Innenauftrag, da grundsätzlich ist die aktivie Verfügbarkeitskontrolle tatsächlich nur für Maßnahmen wie Aufträgen gedacht.

Um nun auch für Kostenstellen eine solche einzurichten besteht die Möglichkeit zur Kostenstelle einen statistischen Innenauftrag anzulegen und auf diesen entsprechend Budget zu erfassen.

SAP empfiehlt nun über eine kundeneigene Substitution im CO (Transakton OKC9), den statistischen Auftrag automatisch mitbuchen zu lassen, wenn eine manuelle Buchung auf die Kostenstelle erfolgt. Dieses funktioniert jedoch nicht bei Umlagen, Verteilungen und andere maschinelle Verrechnungen.

Erfolgt nun eine Buchung wird diese gegen das Budget auf den statistischen Innenauftrag geprüft und es erfolgt eine entsprechende Hinweismeldung.

Ausgangslage:
Ergänzend zur verantwortlichen Kostenstelle des Innenauftrag soll als weitere  Information eine weitere Kostenstelle hinterlegt werden. Hierzu werden mehrere Überlegungen zur Umsetzung angestellt.
 

Userexit für kundeneigene Zusatzfelder im Stammsatz

Im Wesentlichen ist es möglich über sogenannte Userexits Zusatzfelder zu Stammdaten zu erstellen. Dieses ist über die Transaktion CMOD möglich und zum Beispiel für

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

möglich.

Eine Übersicht aller Userexits ist auch auf der Seite easymarketplace.de möglich.
Im Berater-Wiki ist die Nutzung von CMOD anhand eines Beispiels im Eintrag "Customer-Exits" erläutert.

Alternativ können natürlich auch sonstige freie Felder im jeweiligen Stammdatenblatt verwendet werden. Gerade die Stammdaten eines Innenauftrages haben hier einige Felder, die auf unterschiedliche Weise eine Zuordnung von Daten ermöglichen.

Individuelle Stammdatenfelder ändern

SAP selbst empfiehlt im Customizing die Verwendung von individuellen Stammdatenfeldern, die auch durch entsprechendes Customizing eine eigene Bezeichnung erhalten können.
Das Customizing ist in der Transaktion SPRO im Pfad
Controlling > Innenaufträge > Auftragsstammdaten > Bildschirmgestaltung > "Individuelle Stammdatenfelder ändern" erläutert (Hilfe Schaltfläche)

Folgende Daten des Gruppenrahmen "Allgemeine Daten" können hier umbenannt werden.

Insgesamt stehen hier folgende zehn Felder zur Verfügung:

• Antragsteller (AUFK-USER0  Char 20)
• Telefonnummer des Antragstellers (AUFK-USER1 Char 20)
• Verantwortlicher (AUFK-USER2 Char 20)
• Telefonnumer des Verantwortlichen (AUFK-USER3 Char 20)
• Geschätzte Gesamtkosten des Auftrags (AUFK-USER4 Währung 11)
• Antragsdatum (AUFK-USER5 Datum 8)
• Abteilung (AUFK-USER6 Char 15)
• Arbeitsbeginn (AUFK-USER7 Datum 8)
• Arbeitsende (AUFK-USER8 Datum 8)
• Kennzeichen "Arbeitsgenehmigung erteilt" (AUFK-USER9 Checkbox Char 1)

Wie beschrieben war das Ausgangsproblem für das Thema kundeneigene Felder die Anfrage, ob eine zweite Kostenstelle ergänzend zur verantwortlichen Kostenstelle des CO Innenauftrages hinterlegt werden kann.Hier bietet sich dann die "anfordernde Kostenstelle" als Feld an.

Verantwortliche und Anfordernde Kostenstelle im CO Innenauftrag

Ein Beispiel für unterschiedliche Verknüpfungen zu anderen CO Objekten ist hier die verantwortliche und die anfordernde Kostenstelle im Register "Zuordnungen". Die verantwortliche Kostenstelle stellt dabei die organisatorische Zuordnung eines Innenauftrages dar und kann unter anderen für Berechtigungen (z.B. Berechtigungsobjekt K_ORDER) verwendet werden. Wird über einen Investitionsauftrag eine Investitionsmaßnahme abgebildet, so wird die anfordernde Kostenstelle für die Anlage im Bau in den Stammsatz der Anlagenbuchhaltung übernommen.

Innerhalb der Auftragsart kann über die Objektklasse bestimmt werden, ob es sich beim Innenauftrag um einen Investitionsauftrag handelt oder hier bspw. Gemeinkosten abgebildet werden. Über das Auftragslayout oder die Feldauswahl können hier einzelne Felder ausgeblendet bzw. als Muss/Kann Felder definiert werden.

Ebenso käme hier das Feld "anfordernder Auftrag" in Betracht (um bspw. den Hauptauftrag bei Teilprojekten zu identifizieren. Hier stellt sich dann nur die Frage, ob langfristig nicht doch auch das Investitionsmanagement genutzt werden soll, oder besser um nicht Felder zu verwenden, die eigentlich für eine andere Funktion vorgesehen sind, eine andere Alternative ebenfalls überlegenswert und möglicherweise noch flexibler wäre.

Auf diese und andere Alternative, wie die Nutzung der Klassifizierung, wurde im Buch "Schnelleinstieg ins SAP Controlling (CO)" (ISBN 9783960126874 ^*)  hingewiesen... . Für einen Überblick über die Möglichkeiten im Controlling mit SAP ist dieses tatsächlich ein geeignetes Nachschlagewerk :-) Hier wird auch die Auftragslayoutpflege innerhalb des Customizing zur Auftragsart (Transaktion KOT2_OPA) ausführlich beschrieben.

Leseempfehlungen:
Einige aktuelle Literaturempfehlungen habe ich auch im Artikel "Espresso Tutorial SAP Fachbücher Neuerscheinungen und Katalog 2016" festgehalten, wobei ich aktuell hier auch noch zwei Bücher im RUB stehen habe bzw. derzeit eher am SUB als aktuelle Literatur.

Ergänzend zu den kundeneigenen Zusatzfeldern möchte ich nun aber auch etwas ausführlicher auf die Möglichkeiten der Klassifizierung eingehen.

Anwendungsübergreifende Komponente 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.

Hauptanwendungsgebiet der Klassifizierung dürfte jedoch die Verwendung in der Materialwirtschaft sein um entsprechende Stammdaten der Materialien zu erweitern. Aber auch sonst ist die Klassifizierung tatsächlich anwendungsübergreifend und ermöglicht auch die Erweiterung von weiteren Stammdaten, wie auch schon an der Klassenart 010 Lieferantenklasse, 011 Debitorenklasse oder auch 001 Materialklasse zu sehen ist.
 

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 im CO Objekt 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. Hierzu muss die Klassifizierung im jweiligen Objekt aktiviert 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.

Auswertung über Query

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.

Anhand der beiden Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" und "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" (hier im Abschnitt "Merkmal aus Klassifizierung mit auswerten" ) habe ich beschrieben, wie diese Merkmale wesentlich eleganter über eine Query ausgewertet werden können.

Insgesamt sollte das Thema von notwendigen Daten besonders dann überdacht werden, wenn auch die Stammdaten mit anderen Systemen, zum Beispiel Personalabrechnung oder Bestellung per EBP ausgetaucht werden.. Auch hier ist eine gemeinsame Planung zwischen allen Beteiligten und das endgültige Berichtsziel nahezu elementar.

Wie schon im ersten Teil dieses Artikel ("Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage") beschrieben wurde aus einer anderen Hochschule ("erweiterten" KollegInnenkreis) basierend auf eine CO Schulung mit SAP Query (aus der auch viele Anregungen im Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" vorgestellt wurden) die Idee die Stammdaten eines CO Innenauftrages mit einer Einzelpostenliste zu kombinieren und dabei eine Spalte für Ertrag und eine Spalte für Aufwand inklusive Abschreibungen entwickelt und entsprechend umgesetzt. Die hier genutzte Lösung innerhalb der Query möchte ich hier gerne vorstellen.

Im Ergebnis kann hier, vergleichbar zur Saldenliste im PSM-FM (siehe Artikel "Saldenliste für Fonds im Haushaltsmanagement Saldo gegen Ertrag und Saldo gegen Budget") eine Auswertung über bestimmte Innenaufträge aller Erträge und Aufwendungen erfolgen. Ferner können hier sowohl als Selektionsmerkmal als auch für die Liste als Ausgabe entsprechende Stammdaten mit ausgegeben werden.

Basis: Infoset AUFK-COEP und Zustzfelder/Zusatztabellen

Als Grundlage für die Query habe ich ein recht umfangreiches Infoset angelegt, dass sowohl Stammdaten aus CO und PSM-FM als auch die CO Einzelposten aus der Tabelle COEP miteinander in Verbindung setzt.

Als schematische Darstellung sieht das Infoset inklusive Zusatzfelder (mit Coding) und Zusatztabelle, welche beide gelb eingefärbt sind,  wie folgt aus:



Der Aufbau des Infoset und der Zusatzfelder ist im ersten Teil dieses Artikel ausführlich beschrieben. ACHTUNG der Left outer Join gehört zwischen COEP und CSKB und nicht COEP und CSKU (Hintergrund geänderte Kostenartentexte). Hier ist die Zeichnung leider fehlerhaft.

Exkurs: Auswertung Einzelposten COEP statt Summen COSS, COSP

Per Mail wurde ich bezüglich des  Infoset angesprochen, ob es nicht sinnvoller wäre statt der Einzelposten hier die Summentabelle COSP auszuwerten, da dieses einen Performancegewinn für die spätere Query hätte. Der Gedanke der Summentabellen klingt auf den ersten Blick sympathisch hat jedoch einen entscheidenden Nachteil. In der Tabelle COSP werden nur die Primärkosten als Summe gespeichert, die sekundären Kostenarten sind in der Tabelle COSS enthalten. Die COEP hat dafür alle Einzelposten. Ebenso sind die Planbelege ein weiteres Problemfeld, da diese in der Tabelle COEJ hinterlegt sind und ebenfalls eine Herausforderung zur Auswertung bieten. Auf die Auswertung der Plan-Einzelposten bin ich im Artikel "CO Planeinzelposten Objekt und Partnerobjekt auswerten / Mehrere Felder summieren" eingegangen. In diesem Zusammenhang ist auch die Tabelle TJ01 "Betriebswirtschaftliche Vorgänge" interessant, da diese für jeden betriebswirtschaftlichen Vorgang erfasst, wo die erfassten Bewegungsdaten in Tabellenform festgehalten werden.

Zuordnung Infoset zu Query

Das entsprechende Infoset sollte, in der Transaktion SQ02 über die Schaltfläche "Zuordnung zu Rollen/Benutzergruppen" der Benutzergruppe zugeordnet werden in der nun auch die Query erstellt werden soll.

Dieses kann dann in der Transaktion SQ01 erfolgen. In der Query soll nun auf die Gruppierung der Kostenarten nach Ertrag und Aufwand eingegangen werden, sowie die eigentliche Query basierend auf diesem Infoset erstellt werde.

Dazu arbeiten wir auch wieder mit lokalen Feldern in der Query.

Neben der reinen Auswertung von einzelnen Tabellenfeldern beziehungsweise der im Infoset zur Verfügung gestellten Feldern kann innerhalb der Query auch die Ergebnisse dieser Datenbankabfrage verarbeitet werden.

Kurzbezeichnung für Wert und Kostenart

Dazu müssen einzelnen Feldern eine Kurzbezeichnung zugewiesen werden um auf diese in den lokalen Feldern dann Bezug genommen werden zu können.

Hierzu gehen wir nicht in die Grundliste der Query (wo später  auch das Layoutdesign gepflegt wird) sondern wechseln innerhalb der Querypflege mit nächstes Bild (F6) auf die Feldauswahl der Query. Sofern wir uns noch in der Layoutpflege befinden kann über Zurück dorthin gewechselt werden. Alternativ kann auch im Menü über

SPRINGEN->FELDAUSWAHL->FELDAUSWAHL

in die Feldauswahl der Query gewechselt werden. 

Achten Sie bitte darauf, dass über

EINSTELLUNGEN ->EINSTELLUNGEN

der grafischer Query Painter aktiviert ist, wobei dieses auch im Standard der Fall sein sollte. Andernfalls würde sich die Oberfläche zur Querydefinition etwas ändern (was zwar mehr Möglichkeiten bietet, aber leider auch ein wenig am Komfort der Pflege von Query verhindert.

Um den einzelnen Feldern eine Bezeichnung zuzuweisen ist es erforderlich über die Funktion

BEARBEITEN->KURZBEZEICHNUNGEN ->EINSCHALTEN

einzelne Felder eine Kurzbezeichnung zuordnen und mit dieser Bezeichnung dann arbeiten.

Erst nachdem die Kurzbezeichnungen eingeschaltet sind, kann über die Feldauswahl eine Kurzbezeichnung den einzelnen Feldern des Infoset zugewiesen werden.

Hierzu wechseln wir in die Felder der Feldgruppe "CO-Objekt: Einzelposten periodenbezogen" beziehungsweise der Feldgruppe in der Sie die Felder der Tabelle COEP zugewiesen haben.

Hier erhalten nun die Felder "Wert gesamt in Kostenrechnungskreiswährung" und  "Kostenart" eine Kurzbezeichnung. Hier wählen wir die Kurzbezeichnungen WERT und KOA.

Exkurs: Unterschiedliche Währungen im Controlling

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

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

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

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

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

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

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

Ich habe mich daher für WERT für "Wert gesamt in Kostenrechnungskreiswährung" als Feld entschieden.

Lokales Feld für Ertrag, Aufwand und Verrechnung bzw. Umlage anlegen

Die nun zugewiesenenKurzbezeichnungen WERT und KOA sind notwendig, da wir auf diese dann Bezug nehmen, wenn wir ein lokaes Feld mit einer Formel anlegen.
Dieses geht über

BEARBEITEN->LOKALES FELD->ANLEGEN.

Dieses Lokale Feld wird dann in der Feldgruppe angelegt, in der wir uns gerade befinden. Entsprechend sinnvoll ist es soweit in der Feldliste herunterzunavigieren, bis wir in der Feldgruppe sind in der auch die Zusatzfelder Gesperrt, Projektbewertung und VLE (Virtuelle Lehreinheit) hinterlegt sind.

Nun können folgende Felder angelegt werden.

1. Lokales Feld ERTRAG_5
Kurzbezeichnung:  ERTRAG_5
Feldbezeichnung: 5er Ertrag
Überschrift: 5er Ertrag
Eigenschaften:
Gleiche Eigenschaften wie Feld:  WERT
Berechnungsvorschrift:
Hier muss ausnahmsweise keine komplexe Berechnung eingetragen werden, da wir nur eine Bedingung (ein Intervall an Kostenarten) benötigen.

Entsprechen lautet die Berechnung  WERT
und die zugehörige Bedingung
KOA >= 50000000 AND KOA <= 59999999

Alternativ kann dieses auch als
Bedingung:  KOA >= 50000000 AND KOA <= 59999999
Formel: WERT

angegeben werden und Sonst leer gelassen werden. Somit wird das Feld Wert nur im lokalen Feld ausgegeben, wenn die Kostenart zwischen 50000000  und 59999999 liegt.

Genauso definieren wir die beiden übrigen Felder:

2. Lokales Feld AUFWAND_6
Kurzbezeichnung:  AUFWAND_6
Feldbezeichnung: 6er Aufwand
Überschrift: 6er Aufwand
Eigenschaften:
Gleiche Eigenschaften wie Feld:  WERT
Berechnungsvorschrift:
Bedingung: KOA >= 60000000 AND KOA <= 69999999
Formel: WERT

Wobei dieses nun sowohl den Sachaufwand als auch die AfA umfasst.

Daneben legen wir noch ein weiteres Feld für die sekundären Kostenarten der Kosten-Leistungs-Rechnung an über die Verrechnungen und Umlagen erfolgen.3

3. Lokales Feld AUFWAND_9
Kurzbezeichnung:  AUFWAND_9
Feldbezeichnung: Umlage Verrechnung
Überschrift: Umlage Verrechnung
Eigenschaften:
Gleiche Eigenschaften wie Feld:  WERT
Berechnungsvorschrift:

Hier können dann mehrere Bedingungen hinterlegt werden, als Beispiel sind hier drei Nummernkreise der Kostenarten festgelegt:

Bedingung: KOA >= 91000000 AND KOA <= 91999999
Formel: WERT

Bedingung: KOA >= 93000000 AND KOA <= 93999999
Formel: WERT

Bedingung: KOA >= 95000000 AND KOA <= 95999999
Formel: Wert


Für alle anderen Kostenarten könnte nun ein weiteres Feld mit Prüfung angelegt werden, sofern keines der anderen Felder gefüllt ist.Natürlich können auch andere Intervalle (zum Beispiel für Personalkosten, AfA oder Sachkosten) gewählt werden.

Exkurs: Kontenrahmen und Kostenartenintervalle am Beispiel Personalkosten

Nehmen wir als Beispiel den Industriekontenrahmen (IKR). Hier sind die einzelnen Kontenklassen ebenfalls als Intervalle gepflegt.

Innerhalb der Klasse 6 (Betriebliche Aufwendungen) wären die Personalkosten in den Intervallen Löhne (620000 bis 629999), Gehälter (630000 bis 639999) und Personalnebenkosten (640000 bis 649999). Je nach Sichtweise können zu den Personalkosten auch die Sonstigen Personalaufwendungen (660000 bis 669999) betrachtet werden unter die unter anderen die  Aufwendungen für Fort- und Weiterbildung fallen.

Eine ausführliche Beschreibung der hier zugrundeliegenden Kostenartenrechnung  ist im Buch "Schnelleinstieg ins SAP Controlling (CO)" (ISBN 9783960126874 ^*)  zu finden... .



Hier werden auch weitere Intervalle (im Kapitel Kostenartenrechnung) sowie der Industriekontenrahmen IKR ausführlicher erläutert. Eine gute Einführung in das interne und externe Rechnungswesen anhand der SAP Module FI und CO habe ich ferner im Artikel "Schnelleinstieg ins SAP Rechnungswesen mit cat content ;-)" vorgestellt. Sollten Sie sich für SAP Fachliteratur interessieren dürfte auch die digitale SAP-Bibliothek von Espresso Tutorials interessant sein (siehe SAP ebook Flatrate).

In der in diesem Artikel erstellten Query kann, anhand der lokalen Felder, aber schon anhand der Summe der Spalten und der Summe der Spalte Wert kontrolliert werden, ob tatsächlich alle Kosten ordentlich zugeordnet sind. Sollten Sie auch weitere Aufwendungen über Kostenarten beginnend mit 7* buchen, wäre eine weitere künftige Spalte bzw. lokales Feld anzulegen.
 

Grundliste der Query anlegen

Nach Anlage der lokalen Zusatzfelder kann nun die Grundliste der Query angelegt werden.
Hierzu kann über SPRINGEN->GRUNDLISTE->AUFBAU auf die Pflege der Grundlise gewechselt werden in der sowohl das Layout als auch die einzelnen auszugebenden (oder zu selektierenden Felder) ausgewählt werden.

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

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


Tabelle AUFK "Aufragsstammdaten"
Auftragsnummer (L,S) AUFK-AUFNR
Kurztext  (L) AUFK-KTEXT
Arbeitsbeginn (L) AUFK-USER7
Arbeitsende (L) AUFK-USER8

Zusatzfelder (aus Infoset)
G(esperrt) (L) GESPERRT

Tabelle AUFK "Aufragsstammdaten"
Antragsteller (L) AUFK-USER0
Verantwortlicher (L) AUFK-USER2
Abteilung (L) AUFK-USER6

Tabelle FMFINCODE "FIFM: Finanzierungscode"
Finanzierungszweck von Drittmitteln  (L,S) FMFINCODE-FINUSE

Zusatzfelder (aus Infoset)
Projektbewertung (L,S) PBW

Tabelle AUFK "Aufragsstammdaten"
Verantwortliche Kostenstelle (L,S) AUFK-KOSTV


Tabelle COEP "CO-Objekt: Einzelposten periodenbezogen"
Geschäftsjahr (L,S) COEP-GJAHR
Vorgang CO (L) COEP-VRGNG
Belegnummer (L,S) COEP-BELNR
Kostenart (L,S) COEP-KSTAR

Tabelle CSKU "Kostenartentexte"
Bezeichnung Kostenart (L) CSKU-KTEXT

Tabelle COEP "CO-Objekt: Einzelposten periodenbezogen"
Wert gesamt in Kostenrechnungskreiswährung (L) COEP-WKGBTR
Je nach Betrieb kann es hier sinnvoll sein die Währungsfeldposition davor oder dahinter zu setzen. Sofern nur eine Währung genutzt wird kann natürlich auch kein Währungsfeld genutzt werden.

Tabelle COBK "CO-Objekt: Belegkopf"
Erfassungsdatum des Beleges (L,S) COBK-CPUDT
Buchungsdatum  (L) COBK-BUDAT
Benutzername  (L) COBK-USNAM

Tabelle COEP "CO-Objekt: Einzelposten periodenbezogen"
Positionstext (Segmenttext) (L)  COEP-SGTXT

Tabelle COBK "CO-Objekt: Belegkopf"
Belegkopf-Text (L) COBK-BLTXT

Lokale Zusatzfelder (aus der Feldliste der Query)
5er ERTRAG (L)
6er Aufwand (L)
9er UmlageVerrechnung (L)

Zur Zuordnung der Verantwortung kann nun noch die verantwortliche Kostenstelle und natürlich die Lehreinheit mit ausgegeben werden.

Tabelle CSKS "Kostenstellenstammsatz"
Kostenstelle (L) CSKS-KOSTL

CSKT "Kostenstellentexte"
Bezeichnung Kostenstelle (L) CSKT-KTEXT

Tabelle CSKS "Kostenstellenstammsatz"
Verantwortlicher (L) CSKS-VERAK
Abteilung (L) CSKS-ABTEI

Zusatzfelder (aus Infoset)
VLE (virtuelle Lehreinheit) (L) VLE

Damit kann die Query tatsächlich genutzt werden und je Innenauftrag auf Basis der einzelnen Spalten eine Zwischensumme für Ertrag, Aufwand und die interne Verrechnung beziehungsweise der Umlage ausgewiesen werden.

Besonderheiten bei Klassifizierung beziehungsweise Auswerten der Merkmale zur Unterscheidung Drittmittel, Dienstleistung oder Sonstige..

Noch eine kleine Anmerkung zur Klassifizierung. Die Merkmale der Klassifizierung  ermöglichen eine weitergehende Information zum Fond und könnten ebenso auch bei den Innenaufträgen aktiviert werden. Eine gute Übersicht zur Einführung der Klassifizierung habe ich im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" beschrieben. In der erstellten ALV Liste der Query kann dann auch tatsächlich nach einzelnen Merkmalen der Klassifizierung sortiert oder auch gefilert werden. Dieses ist dann wesentlich komfortabler als die Suchfunktion innerhalb der Komponente Klassifizierung von SAP. Auch wenn die Merkmale der Klassifizierung als Selektionsmerkmal in der Query keine Wertauswahlhilfe (F4) anbieten kann es hilfreich sein hier diese ebenfalls als Kriterium zu nehmen.

Somit können alle in der Projektbewertung als DL für Dienstleistung festgelegte beziehungsweise klassifizierten Projekte ausgewertet werden.

Sollten Sie die einzelnen Merkmale einmal von Freitext auf vorgegebene Merkmalswerte umgestellt haben kann die Query Daten in den Merkmalen liefern die im Stammsatz beziehungsweise in der Klassifizierung nicht vorhanden ist beziehungsweise da fehlerhaft nicht ausgewiesen wird.

Als Beispiel konnte das Merkmal PBW früher mit DM2001 gefüllt werden (Drittmittel 2001) und heutzutage werden mit DM, DL, AF bestimmte Merkmale vorgegeben und es kann kein weiteres Merkmal gepflegt werden. Dieses Problem ist im Abschnitt "Sonderfall Inkonsistenz bei Merkmalspflege" im Artikel zur Klassifizierung beschrieben.

Entsprechend spannend kann es daher sein noch weitere Merkmale der Klassifizierung, wie zum Beispiel das Förderkennzeichen des öffentlichen Mittelgeber als weiteres Selektionsmerkmal zu hinterlegen und hier entsprechende Auswertungen zu erstellen. Damit können auch anhand des Förderkennzeichen mit *ESF* alle Projekte des ESF ausgewertet werden.

 

---

Hinweis:

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

---

Ausgangslage
Aus "erweiterten" KollegInnenkreis (andere Hochschule) wurde mir basierend auf eine CO Schulung mit SAP Query die Idee die Stammdaten eines CO Innenauftrages mit einer Einzelpostenliste zu kombinieren und dabei eine Spalte für die Ertrag und eine Spalte für Aufwand inklusive Abschreibungen auszuweisen vorgestellt, so dass am Ende nach Selektion bestimmter Merkmale aus den CO Stammdaten eine passende Einzelpostenauswertung erstellen zu können, die dann auch noch nach Innenaufträgen summiert werden können.

Diese Idee habe ich im kommenden Artikel aufgegriffen und um den ein oder anderen Punkt erweitert. Insgesamt kommt so eine Liste vergleichbar der Transaktion KOB1 (Aufträge Einzelposten Istkosten anzeigen) heraus. Als Summenbericht ist eine solche Auswertung problemlos im Report Writer / Painter möglich, wie im Artikel "Erweiterung Report Writer Berichtsbibliothek 1CT zur Darstellung rollierendes Geschäftsjahr für Kostenstelle und Innenauftrag" beschrieben. Allerdings können hier nicht alle Stammdaten des auszuwertenden CO-Objekt in unseren Fall also der Innenauftrag als Information oder auch als Selektionsfeld ausgewählt werden.

Entsprechend verfolgen wir mit einer neuen Query einen vergleichbaren Ansatz zu der Query im Artikel "Query Einzelpostenliste IST über CO Objekte (Auflösen von Innenauftrag, Kostenstelle) sowie Benutzerstammdaten und Erfassungsdatum". Jedoch sollen hier nicht einfach die CO-Objekte als Kostenstelle oder Innenauftrag ausgegeben werden sondern gerade die Innenaufträge als Auswertungsmerkmal gesondert betrachtet werden um beispielsweise alle Innenaufträge mit einen bestimmten Merkmal (zum Beispiel über das Feld "Arbeitsgenehmigung liegt vor" oder anhand der verantwortlichen Kostenstelle) auszuwerten. So kann das CHECKIN Feld zum Beispiel zur Kennzeichnung von vollkostenpflichtigen Projekten genutzt werden.

Wie bereits in der Überschrift  erwähnt, wird dieser Artikel in zwei Teilen erscheinen. Im ersten Teil wird die Grundlage für die Auswertung in Form eines Infoset erstellt werden. Hierbei sind auch viele kleine neueren Erkenntnisse rund um die Kombination von Stammdaten aus PSM-FM und CO mit eingebunden. Ferner wird innerhalb des Infoset dank Zusatzfeldcoding auch manches Datum schon vorbereitet wofür es in vorherigen Artikeln relativ umfassende komplexe Berechnungen in der Query gab. Es lohnt sich also tatsächlich diesen recht langen Artikel komplett zu lesen.
 

Infoset Stammdaten Innenauftrag und CO Einzelposten im Ist

Hierzu wurde als erstes ein Join über folgende Tabellen angelegt.



Das Infoset ist dabei vergleichbar des oben beschriebenen Artikel angelegt, so dass sowohl die Einzelpositionen des CO Beleg als auch die Belegkopfdaten ausgewertet werden können. ACHTUNG: Dabei ist jedoch zu beachten, dass der Left Outer Join zwischen CSKB und COEP und nicht CSKU und COEP gesetzt werden sollte. Hier ist die Darstellung leider fehlerhaft.

Nun sollen aber zu den Stammdaten aus CO (beziehungsweise der Tabelle AUFK "Auftragsstammdaten") noch weitere Informationen über Zusatzfelder und Zusatztabellen mit ausgegeben werden.

Bisherige Vorgehensweise (wird im weiteren Verlauf dieses Artikels erheblich verbessert)

Hier bietet sich die Gelegenheit die in der Artikelserie

1. "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck oder auch Status GESPERRT bei Innenaufträgen"
2. "Query über verantwortliche Kostenstelle des Innenauftrag - Bestimmung der Lehreinheit im Fachbereich durch Teil der Kostenstellennummer"
3. "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM"
4. "Weitere Zusatzfelder im Infoset mit ABAP Coding zur Verwendung in SAP Query über die Tabellen AUFK und FMFINCODE"

bereits vorgestellten Methoden sinnvoll zu aktualisieren und die zum Beispiel im Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" gewonnenen Erkenntnisse ebenfalls einzuarbeiten und hier ein wenig das Infoset anzupassen beziehungsweise für mich neure und in meinen Augen auch intelligentere Methoden zwecks Verknüpfung von Stammdaten aus CO und PSM-FM zu erstellen. Daneben hat sich auch bei der Erstellung eines Feldes zur Darstellung der virtuellen Lehreinheit eine Menge entwickelt, so dass diese nun direkt im Infoset als Zusatzfeld ermittelt werden kann.

Da dieses Vorhaben etwas umfangreicher ist, wurde dieser Artikel in einen Teil zur Datengrundlage (Infoset) und der Auswertung des Infoset in Form einer Query aufgeteilt.
 

Erweiterung des Infoset über Zusatzfelder

Über die Schaltfläche Zusätze (F5) bzw. innerhalb der Transaktion SQ02 (Pflege des Infosets) über  SPRINGEN-> ZUSÄTZE ZUM KNOTEN kann ein zusätzliches Feld in ein Infoset definiert werden, welches nicht direkt in der auszuwertenden Tabelle erscheint. Ich möchte im folgenden Artikel vier Zusatzfelder anlegen um hier wesentlich weitergehende Auswertungsmöglichkeiten als das Lesen einer Tabelle oder eines Infoset zu ermöglichen.

Innerhalb des nun aufgerufenen Register Zusätze kann über die Schaltfläche "Anlegen" ein Zusatzfeld erstellt werden. Es erscheint eine Maske in der der Name des Zusatzfeldes angegeben werden soll und die Art der Zusatzinformation.

Im Einzelnen können dieses Zusatztabelle, Zusatzfeld, Zusatzstruktur und Coding sein. In den folgenden drei Abschnitten soll hier Zusatzfelder erstellt werden. Wobei eines davon später für das Einfügen einer Zusatztabelle genutzt wird. Wichtig ist es nach Eingabe des Zusatzfeldes auch die Eigenschaften wie Langtext, Überschrift sowie Textlänge und Typ definiert werden. Teilweise kann hier auch mit LIKE Referenz gearbeitet werden, so dass die Feldeigenschaften eines referenzierten Tabellenfeldes entsprechen.

Damit ist dann grundsätzlich ein Feld angelegt allerdings enthält es (anders als beim Einfügen einer Zusatztabelle, die direkt mitsamt ihren Daten ins Infoset geladen wird) keine Werte. Um nun eine entsprechende Wertzuweisung im Infoset zu bekommen kann hier mit Coding zum Feld gearbeitet werden.

Nachdem ein Feld jedoch angelegt ist kann über die Schaltfläche "Coding zum Zusatz" ein passendes ABAP Coding für das Feld hinterlegt werden über das wiederum eine Datenbankabfrage erfolgen kann. In den folgenden Abschnitten habe ich das von mir eingefügte Coding angegeben und kurz erläutert.

Berechtigungen für Zusatzfelder mit ABAP Coding

Für die Pflege von Zusatzcoding sind jedoch weiter gehende Basisberechtigungen erforderlich. Hierzu werden die Berechtigungen auf das Berechtigungsobjekt S_DEVELOP und die Berechtigungsfeldwerte Objekttyp PROG, Objektname AQ* sowie die Aktivitäten 01 und 02 geprüft. Da es sich hier um recht weitgehende Berechtigungen handelt, sollten diese auch nur im Entwicklungssystem vergeben werden. Die Berechtigungsprüfung erfolgt ebenfalls, wenn die Query, wie im Artikel "Transport von SAP Queries (DL/UL)" beschrieben, per Dateiupload ins Testsystem oder Produktivsystem transportiert werden soll. Das Infoset selbst lässt sich nach einem erfolgreichen Upload noch bearbeiten, lediglich das Coding ist durch die Berechtigungsprüfung vor weiteren Änderungen geschützt.

In den folgenden Abschnitten wird auf die einzelnen Zusatzfelder mit ihren Eigenschaften und zugehörigen Coding zum Zusatzfeld eingegangen.

Zusatzfeld Gesperrt (Sperrkenzeichen auswerten)

Auch hier wird wieder ausgewertet, ob ein Innenauftrag den Systemstatus Gesperrt (in der Transaktion KO02 "Innenauftrag ändern" per Bearbeiten->Sperre setzen) hat.

Hierzu wird ein Zusatzfeld GESPERRT mit den Eigenschaften Typ C (Charcter) und einer Länge von 001 angelegt. Dahinter wird als Coding folgende Anweisung hinterlegt:

DATA: L_AUFKOBJ type AUFK-OBJNR.
DATA: L_TEMP type AUFK-OBJNR.
L_AUFKOBJ = AUFK-OBJNR.
SELECT  SINGLE objnr FROM JEST into L_TEMP
    WHERE stat = 'I0043'
    AND objnr = L_AUFKOBJ
    AND inact = ''.
IF sy-subrc <> 4.
GESPERRT = 'X'.
ELSE.
CLEAR GESPERRT.
ENDIF.

Damit der Sperrstatus ermittelt werden kann wird anhand der Objektnummer des Innenauftrag (Feld AUFK-OBJNR) in der Tabelle JEST geprüft ob der Status I0043  gesetzt ist.

Zur Verdeutlichung des Zusammenhang sei auf folgende Grafik verwiesen:


Wobei das Thema Systemstatus auch sehr umfassend in den beiden Artikeln:

• "SAP Query: Systemstatus CO Innenauftrag"
• "Änderungsbelege zu Systemstatus (JEST) bei Innenaufträgen per Query auswerten"

erklärt ist und für diese Auskunft lediglich die Information ausreicht, ob der aktuelle Innenuaftrag gesperrt ist oder eben nicht.


 

Zusatzfeld VLE zur Darstellung virtueller Lehreinheit aus Teilstring der verantwortlichen Kostenstelle sofern nicht in einen anderen Feld ein Wert steht

Innerhalb der Kostenstellen einer Hochschule sind auch entsprechend Lehreinheiten mit den ersten vier Ziffern verschlüsselt. Sofern abweichend zu den ersten vier Ziffern innerhalb der Fachbereichskostenstellen eine andere Lehreinheit der Kostenstelle zugeordnet werden soll, ist diese im Feld Teletexnummer (welches nicht mehr für andere Zwecke verwendet wird, ausgewiesen.

Die Ausgabe der verantwortlichen Kostenstelle ist relativ aufwändig innerhalb von lokalen Zusatzfeldern in einer Query gelöst worden. Die hier genutzte Vorgehensweise ist im Artikel "Query über verantwortliche Kostenstelle des Innenauftrag - Bestimmung der Lehreinheit im Fachbereich durch Teil der Kostenstellennummer" beschrieben worden.

Diese Methode hat jedoch den Nachteil, dass jede Query erneut solche Felder und Formeln definiert bekommen muss. Entsprechend positiv wäre es natürlich, wenn eine solche Erhebung direkt im Infoset zum Beispiel über ein Zusatzfeld mit passenden Coding erfolgen kann.

Ein Auslesen der ersten vier Ziffern einer Kostenstelle über eine IF Bedingung ist mir soweit auch gelungen, allerdings hatte ich Probleme eine Abfrage zu erstellen, dass sofern das Feld Teletexnummer gefüllt ist, diese als Lehreinheit genommen wird.

Auf fico-forum.de hatte ich hier eine sehr hilfreiche Unterhaltung mit MrBojangles (Autor des Blog  SAPManDoo) im Beitrag "Query: Auslesen Stammdaten (Zusatzcoding ABAP) Problem SELECT Statement AUFK-KOSTV und CSKS-TELTX".

Das Ergebnis unserer Unterhaltung, inklusiver einer Anpassung für den Fall, dass die Kostenstelle nicht nur numerisch sondern auch Buchstaben enthält habe ich dann wie folgt als Coding zum Zusatzfeld VLE eingebaut.

Hierbei hat das Zusatzfeld VLE durch LIKE-Referenz die Eigenschaften des Tabellenfeldes CSKS-TELTX erhalten (Typ C und Länge 030).

Rahmenbedingungen:
Es werden achtstellige Kostenstellen verwendet, sofern die verantwortliche Kostenstlele des Innenauftrag zwischen 10000000 und 12345678 liegt sollen die ersten vier Ziffern der Kostenstelle als Wert für die Lehreinheit genommen werden.

Ein Sonderfall stellt nun noch die Kostenstelle 47110000 dar. Hier soll als Lehreinheit die 1047BE ausgegegeben werden. Ferner sollen die Kostenstellen der betrieblichen Einrichtung der Kostenstellen 20815000 bis 20815999  der Lehreinheit 208BE und 24300000 bis 24399999 der Einrichtung 243BE zugeordnet werden.

In allen anderen Fällen soll die verantwortliche Kostenstelle des Innenauftrages (aus der Tabelle AUFK-KOSTV) ausgewiesen werden.

Problematisch dabei ist, dass wir zwar achtstellige Kostenstellen nutzen, in SAP jedoch insgesamt zehn Stellen vorgesehen sind, so dass die Kostenstelle aus dem  Tabellenfeld  AUFK-KOSTV mit führenden 00 ausgegeben würden. Mein erster Gedanke wäre daher den erhaltenen Wert mit * 1 zu multiplizieren und so eine Zahl zu erhalten. Hier wurde ich im Forum zu Recht darauf hingewiesen, dass sobald die Kostenstelle auch nur einen Buchstaben enthält ein "ABAP Dump" erzeugt wird. Hier ist eine wesentlich schönere Variante durch die Anweisung NO-ZERO die führenden 00 aus dem Feld zu entfernen und deiesen Wert als VLE zu speichern.

Abschliessend soll nun noch geprüft werden, ob das Feld CSKS-TELTX (Teletexnummer im Kostenstellenstammsatz) mit einen Wert gefüllt ist und dieser Wert in jeden Fall unabhängig der anderen Bedingungen ausgegeben werden.

Hierzu ist eine entsprechende SELECT Abfrage über die Kostenstellen durchgeführt worden. Besonders gelungen empfinde ich hierbei, dass die Gültigkeit des Kostenstellenstammsatzes dahingehend überprüft wird, ob die Information zum Datum der Auswertung (SY-DATUM auch gültig ist, da sich das Feld ja auch auf Basis von zeitabhängigen Daten bei der Kostenstelle ändern kann. Durch ne space wird auch direkt festgehalten, ob die Teletexnummer einen Wert enthält. Sollte dieses der Fall sein, bekommt das Zusatzfeld VLE den Wert der lokalen Variable L_CSKSTELTX zugewiesen, andernfalls den Wert, der anhand der IF Bedingung ermittelt wurde.

Das auf diese Anforderungen erstellte (beziehungsweise angepasste) Coding sieht dann wie folgt aus:

DATA: L_CSKSTELTX type CSKS-TELTX.
IF AUFK-KOSTV => '0010000000' AND AUFK-KOSTV =< '0012345678'.
WRITE AUFK-KOSTV(6) TO VLE NO-ZERO .
ELSEIF AUFK-KOSTV = '0047110000'.
  VLE = '1047BE'.
ELSEIF AUFK-KOSTV => '0020815000' AND AUFK-KOSTV =< '0020815999'.
  VLE = '208BE'.
ElSEIF AUFK-KOSTV => '0024300000' AND AUFK-KOSTV =< '0024399999'.
  VLE = '243BE'.
ELSE.
  WRITE AUFK-KOSTV TO VLE NO-ZERO .
ENDIF.
* bei gefülltem TELTX VLE auf TELTX setzen
SELECT teltx FROM csks INTO L_CSKSTELTX up to 1 rows
  WHERE kokrs = AUFK-KOKRS
  AND kostl = AUFK-KOSTV
  and datbi >= SY-DATUM
  and teltx ne space.
ENDSELECT.
IF sy-subrc = 0.
    VLE = L_CSKSTELTX.
ENDIF.

Nebenbei ist ein solcher fachlicher Austausch mit ein Grund, warum ich immer noch Blogs, Foren und Wikis als ein sehr hilfreiches Arbeitsmittel betrachte und sehr froh darüber bin, dass es immer noch eine Community gibt in der sich gegenseitig geholfen wird. Ein wenig hoffe ich sowohl hier im Blog als auch in einigen Onlineforen meinen Part dazu beitragen zu können. Sehr allgemein habe ich dieses Thema  im Artikel "Praktische Nutzung von social media Diensten für meinen Arbeitsalltag" angesprochen.

Stammdatenfelder aus Fond (PSM-FM) ergänzend zum Innenauftrag ausgegeben

In den beiden Artikeln "SAP Query ABAP Coding im Zusatzfeld für Verknüpfung Innenauftrag und Fond bzw. Finanzierungszweck oder auch Status GESPERRT bei Innenaufträgen" und  "Weitere Zusatzfelder im Infoset mit ABAP Coding zur Verwendung in SAP Query über die Tabellen AUFK und FMFINCODE" wurden einzelne Felder aus der Tabelle FMFINCODE durch eine Select Abfrage und SHIFT Anweisung ausgelesen und einzeln dem Infoset hinzugefügt.

Hintergrund ist, dass das Feld AUFK-AUFNR  in der Datenbank als Character mit 12 Zeichen und das Feld FMFINCODE-FINCODE als Character mit 10 Zeichen definiert ist.

Selbst wenn die Auftragsnummer und die Nummer des Fond übereinstimmen können beide Felder nicht miteinander in Form eines Infoset verknüpft werden, da diese eine "illegale Verknüpfung" wäre, da rein technisch die Felder nicht übereinstimmen.

Innerhalb des Abschnitt "Zusatzfeld ZAUFNR (Übernahme AUFK-AUFNR als FMFINCODE-FINCODE" im Artikel "SAP Query innerhalb des SAP Moduls PSM FM beziehungsweise Haushaltsmanagement" wurde nun eine clevere Alternative dargestellt.

Zusatzfeld ZAUFNR zur Verknüpfung von Innnenauftrag und Fond

Hierzu wurde das Zusatzfeld ZAUFNR mit per LIKE-Referenz FMFINCODE-FINCODE erstellt was in den folgenden Abschniten als Hilfsfeld genutzt werden kann.

Als erläuternde Überschrift und Langtext kann "Auftragsnummer 10 stellig" genommen werden.

Das in meinen Augen clevere Coding beschränkt sich auf einen Einzeiler in dem dem Feld per Offset die Auftragsnummer aus der Tabelle AUFK zugewiesen wird.

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

ZAUFNR = AUFK-AUFNR+4(8).

Hierbei bedient sich das Coding der Technik eines Offsets.

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

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

Im Ergebnis haben wir nun das Feld ZAUFNR, welches die gleichen Eigenschaften wie das Feld FINCODE innerhalb der Tabelle FMFINCODE hat.

Nun kann das Feld für verschiedene Formen der Verknüpfung genutzt werden.

SAP Query: Reihenfolge des Codeabschnittes

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

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

Zusatztabelle FMFINCODE

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

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

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

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

WHERE FIKRS  =  AUFK-BUKRS

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

AND FINCODE = ZAUFNR

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

Merkmal aus Klassifizierung mit auswerten

Nehmen wir an, dass im Rahmen der Klassifizierung von Fonds im Modul PSM-FM die Projektbewertung in ein Merkmal festgehalten wird. Dann ist auch die im Artikel "SAP Query - Auswertung Merkmale der Klassifizierung am Beispiel Fonds in PSM-FM" erheblich erleichtert.

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

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

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

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


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

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

CONCATENATE  'KRK ' ZAUFNR INTO L_OBJFOND RESPECTING BLANKS.

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

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

Zum Abschluss können alle Zusatzfelder und die Felder der Zusatztabelle als Felder in den Feldgruppen des Infoset übernommen werden.

Persönlich habe ich mir angewöhnt, für die Zusatztabelle eine eigene Feldgruppe anzulegen und auch die Zusatzfelder in einer Extra Feldgruppe mit aufzunehmen.

Schematisch betrachtet sieht der technische Aufbau unseres Infoset nun wie folgt aus:


ACHTUNG: Auch hier hat sich in der Zeichnung ein Fehler reingeschlichen, da der left outer join zwischen CSKB und COEP und nicht CSKU und COEP sein sollte.

Damit können in einer Query nun sowohl Stammdaten aus CO / PSM-FM als auch die Ist-Einzelposten ausgewertet werden. Daher sollten auch alle Tabellenfelder mit in das Infoset in Feldgruppen mit aufgenommen werden. So kann später die Query auch sehr flexibel angepasst werden.

Die Idee der eingangs angesprochenen freundlichen Hochschule aus der Nachbarschaft die einzelnen Felder nach Art der Verwendung zu gruppieren wird im zweiten Teil dieses Artikel dargestellt. Hier soll nur erst einmal die Datengrundlage für die Query geschaffen werden.

Der zweite Teil ist im Artikel "Query Einzelpostenliste Innenauftrag mit Ausweis Ertrag und Aufwand Zweiter Teil Query zur Datenaufbereitung" ebenfalls online zu finden.

 

---

Hinweis:

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

---

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.

---

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:

 

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.

---

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.


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.

---

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




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.

---

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.

---

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:




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.

---

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)

Im Artikel "Änderungen und Nacharbeiten nach Einspielung SAP ERP 6.0 Enhancement Package 8 (EHP 8) insbesondere im CO" ist diese aber acuh andere "neue" Transaktionen rund um SE16 wie SE16T, SE16S und SE16SL vorgestellt (siehe dazu den Abschnitt "SAP Basis Zentraler Einstieg Suchfunktionen").

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:


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.

---

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.

---

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.