Die beiden Artikel "SAP Query: Einzelpostenliste KAMV für Umbuchung in Planversion" und "Weiterentwicklung SAP Query Einzelpostenliste Vorgang KAMV (manuelle Verrechnung) und KZPI (Gemeinkostenzuschläge) für Nacherfassung in Planversion" haben bisher schon eine Lösung beschrieben um für eine Plankopie von Ist nach Plan auch die Werte aus der der manuellen Kostenverrechnung im Ist (Transaktion KB15 bzw. KB15N, Vorgang KAMV) bzw. der Gemeinkostenzuschlagsverrechnung (Vorgang KZPI) nachzubuchen.

Hierzu nutzen wir eine Eigenentwicklung die mit Sender und Empfänger eine Planwertumbuchung vergleichbar der Kostenverrechnung nutzbar macht.

Bisher hatte ich hier, quasi lösungsorientiert, eine Query entwickelt die eine Vorlage für eine Korrekturbuchung mit Sender und Empfänger Beziehung liefert.

In beiden Artikeln fehlte aber die Begründung, warum eine solche Lösung notwendig ist, bzw. warum durch eine Plankopie (KP98 Ist in Plan für Kostenstellen bzw. KO15 für Innenaufträge) diese Werte nicht möglich zu übertragen sind.

An dieser Stelle kann ich, da das Thema aktuell einmal wieder angesprochen worden ist, auf die beiden SAP Hinweise "407984 - Ist in Plan Kopieren: Vorgehensweise" und "209432 - Ist in Plan kopieren: Entlastung wird kopiert" verweisen.

Zusammengefasst sind die Kopiertransaktionen nicht dafür da, die Vorlagewerte 1:1 zu "spiegeln" sondern sind eine reine Hilfstransaktion für eine später durchzuführende manuelle Planung. Es werden nur solche Daten in die Zielversion kopiert, die auch durch eine manuelle Planung bearbeitet werden können.

Die Daten aus der manuellen Kostenverrechnung (KAMV) werden nicht berücksichtigt, da es im SAP Standard nichts Vergleichbares dazu gibt.

Ebenso ist auch bei der Gemeinkostenzuschlagsverrechnung (KZPI) darauf zu achten, dass nur die Entlastungen kopiert werden, sofern die Partnerobjekte nicht planintegriert sind. Belastungen werden nie kopiert. Für planintegrierte Partnerobjekte und zur Darstellung der Belastungen ist es daher erforderlich, die Zuschlagsrechnung auch im Plan abzubilden.

Die Alternative wäre die Planwerterfassung anhand der oberen Query sowohl für den Vorgang KAMV als auch KZPI.

Kurzer Exkurs am Schluß: Plankopie und Hochschulcontrolling

Auch wenn die Plankopie seitens der SAP als Planungshilfe gedacht ist und nicht zur vollständigen Spiegelung der Ist-Daten als Plan-Daten vorgesehen ist, hat eine vollständige Plankopie, zumindest im Hochschulcontrolling, eine besondere Bedeutung.

Hintergrund einer solchen Kopie ist, dass wir im Rahmen des CO Jahresabschluss eine Kostenträgerrechnung (KTR) und Hochschulfinanzstatistik erstellen, die bestimmte Verrechnungen im Plan statt im Ist abbilden. So erfolgt in der KTR eine Verrechnung aller Kosten und Erlöse auf die Produkte und Projekte einer Hochschule. Dazu gehören unter anderen auch die Studiengänge welche nicht nur direkte Kosten sondern auch die Kosten der Gebäude, Verwaltung und anderen Einrichtungen abbilden.

Wie dieses umgesetzt wird ist anhand eines Betriebsabrechnungsbogen (BAB) im Artikel "Statistische Kennzahlen für Verrechnung in SAP - Umlage und Verteilung nicht nur im Hochschulcontrolling und Hochschulberichtswesen" erläutert. Die Studiengänge sind dabei als CO Innenaufträge abgebildet und werden, wie im Artikel "Innenaufträge als Empfänger von Umlagezyklen (KSUB)" beschrieben als Kostenträger behandelt.

Neben Kosten und Erlöse können hier auch diverse andere Auswertungen über die passenden Kennzahlen erfolgen. Im Artikel "Leistungsmengen im Grundbudget je Fächergruppe (Cluster) im Vergleich oder bedingte Formatierung für Minimalwerte und Maximalwerte" ist dies dann zum Beispiel im Excel erfolgt.

Technisch funktioniert dies mit statistischen Kennzahlen, so dass ich an dieser Stelle gerne auch auf die Artikel "Auswertung Statistische Kennzahlen auf Innenaufträge für Lehrimport und Lehrexport auf Ebene Studiengänge" und  "Hochschulcontrolling: Vergleich Lehrimport von Studiengängen und Kostenanteile einzelner Lehreinheiten - Abschnitte mit abgeleiteten Kennzahlen im Report Painter" verweise.

Aber auch die unterschiedlichen Möglichkeiten der Kostenumlage und Kostenverteilung im Artikel "Grundlagen: Wohin mit den Kosten? Leistungsverrechnung, Kostenverteilung und Kostenumlage im SAP CO-OM." sowie eine Auswertung der Kosten im Artikel "ReportWriter: Ergebnisse Planumlage (KSUB) je Partnerobjekt" als einen guten Ausgangspunkt für eine solche Verrechnung ansehe. Das Spannende im Hochschulcontrolling und Hochschulberichtswesen ist aber, dass oft noch weitere Anforderungen an das Berichtswesen gestellt werden.

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

 

Rückblick

Ausgangslage:

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

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

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

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

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

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

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

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

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

Zur Erinnerung Z_WERT, Z_ALT, Z_NEU

Lokales Feld Z_WERT

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

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

festgehalten.

Exkurs: Unterschiedliche Währungen im Controlling

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

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

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

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

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

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

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

Die Berechnungsvorschrift zum lokalen Feld lautet:

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

Partner und Objekt als Grundlage Z_ALT und Z_NEU

Die folgenden Felder beziehen sich auf die Felder

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

Lokales Feld Z_ALT

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

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

Lokales Feld Z_NEU

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

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

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

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

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

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

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

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

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

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

Entsprechend kann ich folgende Hilfsfelder anlegen in der Query:


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


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


Nun lege ich vier weitere Felder an:

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

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

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

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


Dazu habe ich im Infoset ein Zusatzfeld angelegt.

Zusatzfeld ZCOKAMV
LIKE-Referenz   COEP-KSTAR

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

 

Coding zu Zusatzfeld ZCOKAMV

CLEAR ZCOKOMV.

* Damit wird der Wert erst einmal auf leer gesetzt.

ZCOKAMV = COEP-KSTAR.

* Nun wird die ursprüngliche Kostenart zugewiesen.

IF COEP-KSTAR CO '1234567890'.

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

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

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

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

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

* Dies bedeutet aus Kostenart 93991234 wird 93981234

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

* Daneben können noch weitere Kostenarten ausgestauscht werden.

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

ENDIF.
ENDIF.
 

Dieses Zusatzfeld bekommt in der Query dann die Bezeichnung ZZKAMV.

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

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

Formel:
ZZKAMV

Fazit

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

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

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

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



Im Buch »Berichtswesen im SAP®-Controlling« bin ich ausführlich auf dies Thema eingegangen.
  Vielleicht finden sich hier ja auch noch weitere Anregungen für den Aufbau eines Berichtswesen mit SAP nicht nur für CO im Buch.
 
Das Thema SAP Query ist immer wieder als Berichtstool ein klein wenig unterschätzt, daher habe ich auch ein eigenes Kapitel im Buch gewidmet. Daneben gibt es aber auch hier im Blog immer einmal wieder einen aktuellen Artikel. Ebenso versuche ich in meinen Vorträgen Begeisterung für das Berichtstool SAP Query zu wecken.
 

---

Hinweis:

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

---

Ausgangslage:

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

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

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

Lösungsansatz: Query über Vorgang KAMV

Ein direktes Auswerten der Tabelle COEP ist relativ mühsam, da hier sowohl auf die Vorzeichen als auch die zu exportierenden Beträge geachtet werden müssen. Zumindest die Aufbereitung nach Sender und Empfänger ist hier im Rahmen einer Query etwas einfacher. Genauso wie bei der Auswertung nach COEP werden als Selektionskriterien das Geschäftsjahr, der Vorgang ("KAMV") als auch das B/Entl.Kennzeichen ("S") verwendet. Dieses hat den Hintergrund, dass jeder Beleg in der COEP sowohl mit Soll als auch mit Haben (also zwei Positionen je Beleg) hinterlegt sind, der Betrag aber nur einmal korrigiert werden soll. Die so gewonnenen Einzelposten können dann entsprechend zusammengefasst werden.

Entsprechend kann die Tabelle COEP als Grundlage einer SAP Query verwendet werden. Als optionale Bereicherung um die Bezeichnung und die Kostenartentypen können hier auch die Tabellen CSKU und CSKB mit der Tabelle COEP betrachtet werden.

Infoset definieren
Tabellen:
COEP - CO-Objekt: Einzelposten periodenbezogen
CSKB - Kostenarten (Kostenrechnungskreisabhängige Daten)
CSKU - Kostenartentexte

Verknüpfungen:
Folgende Felder werden hierbei miteinander verknüpft.

COEP-KSTAR <-> CSKB-KSTAR
COEP-KSTAR CSKU-KSTAR
Bei der Verknüpfung der Tabelle COEP und CSKB handelt es sich um einen "left outer join". Diese Verknüpfungsart kann durch die rechte Maustaste auf "left outer join" genutzt werden. Diese kann genutzt werden, um auch Belege anzugeben, wenn die Verknüpfung keine übereinstimmende Werte ergibt, bspw. weil keine Bezeichnung in der Kostenart ausgegeben werden.

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

Nun kann im weiteren die Query definiert werden.

 

1.) Query definieren

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

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

COEP - CO-OBjekt: Einzelposten periodenbezogen
Kostenrechnungskreis (S) COEP-KOKRS
Be-/Entlastungskennzeichen (L,S) COEP-BEKNZ
Geschäftsjahr (L,S) COEP-GJAHR

CSKB - Kostenarten (Kostenrechnungskreisabhängige Daten)
Kostenartentyp (L) CSKB-KATYP
Datum gültig bis (S) CSKB-DATBI
Gültig bis wird genommen, sofern es Änderungen innerhalb der CSKB gab um zu vermeiden, dass hier zwei Werte ausgegeben werden


COEP - CO-OBjekt: Einzelposten periodenbezogen
Vorgang CO (L,S) COEP-VRGNG
Belegnummer (L) COEP-BELNR
Objektnummer (L,S) COEP-OBJNR
Kostenart (L,S) COEP-KSTAR

CSKU - Kostenartentexte
Allgemeine Bezeichnung (L) CSKU-KTEXT

COEP - CO-OBjekt: Einzelposten periodenbezogen
Wert gesamt in Kostenrechnungskreiswährung (L) COEP-WKGBTR
Partnerobjekt (L,S) COEP-PAROB


Soweit wäre diese Query beinahe identisch zur Auslesung der Tabelle COEP bspw. mit SE16.
Um nun aber abhängig vom Wert die Daten aufzubereiten wird hier mit "lokalen Feldern" vergleichbar zur Erweiterung der Query Stammdaten CO Kontrolle Verantwortliche genommen.
 

2. Kundeneigene Felder in der Query anlegen

Für die Anlage kundeneigener Felder muss als erstes ein Bezug zu den zu verwendenden Feldern innerhalb der Query gegeben sein.

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

Über
BEARBEITEN->KURZBEZEICHNUNG
kann für die einzelnen Felder eine Kurzbezeichnung eingestellt werden.
Nun werden rechts neben den Datenfeldern Eingabefelder für die Kurzbezeichnung angegeben.
Hier erhalten nun folgende Felder eine Kurzbezeichnung:

Innerhalb CO-Objekt: Einzelposten periodenbezogen (Tabelle COEP)
Wert gesamt in Kostenrechnungskreiswährung -> WERT
Objektnummer -> OBJEKT
Partnerobjekt -> PARTNER



Diese Kurzbezeichnung sind notwendig, da wir auf diese dann Bezug nehmen, wenn wir ein eiegens Feld mit einer Formel anlegen.
Dieses geht über
BEARBEITEN->LOKALES FELD->ANLEGEN

Dieses Lokale Feld wird dann in der Feldgruppe angelegt, in der wir uns gerade befinden. Elegant wäre es natürlich, wenn wir im Infoset eine entsprechende leere Feldgruppe definiert hätten, es geht aber auch ohne.

Insgesamt werden hier drei Felder angelegt Z_ALT für dem Semder (Soll) Z_NEU für den Empfänger (Haben) und Z_WERT für den eigentlichen Wert.

Die lokalen Felder haben hierbei dann folgende Eigenschaften:

a) Feld Z_ALT
Das lokale Feld hat folgende Eigenschaften:

Kurzbezeichnung ALT
Feldbezeichnung Z_ALT
Überschrift Z_ALT


Innerhalb der Sachgruppe kann un die Feldgruppe des Infoset gelegt werden. Dieses ist dann der Bereich, wo das lokale Feld angelegt worden ist.

Als Feldeigenschaften könnten wir nun Textfelder, Rechnfelder etc. hinterlegen. Hier geben wir jedoch die gleichen Eigenschaften wie OBJEKT. Da es sich bei Objekt und PARTNER um die Objektnummer (KS* oder OR*) handelt, ist es eigentlich egal auf welches von beiden Bezug genommen wird. Auf diese Weise werden die Eigenschaften des Tabellenfeldes vererbt. Alternativ hätte man auch Textfeld mit 20 Zeichen nehmen können.
Da nun der Sender / Empfänger abhängig vom Wert ermittelt werden soll legen wir eine Berechnungsvorschrift an. Dazu klicken wir auf "KOMPLEXE BERECHNUNG".

Nun können wir drei Bedingungen und eine sonstige Alternative angeben.

Dieses nutzen wir wie folgt:
Bedingung:
WERT > 0
Formel:
PARTNER

Ist der Wert positiv wird das Partnerobjekt als Sender genommen.

Bedingung:
WERT < 0
Formel:
OBJEKT

Ist der Wert negativ wird die Objektnummer als Sender genommen.

Sonst
WERT

Somit wird bei einer 0 der Wert ausgegeben.

b) Feld Z_NEU
Das lokale Feld hat folgende Eigenschaften:

Kurzbezeichnung NEU
Feldbezeichnung Z_NEU
Überschrift Z_NEU

Hier hat das Feld die gleichen Eigenschaften wie das Feld PARTNER.

Als Formeln wird folgende komplexe Berechnung hinterlegt:

Bedingung:
WERT > 0
Formel
OBJEKT

Bedingung
WERT < 0
PARTNER

Sonst
WERT

Im Grunde ist dieses die umgedrehte Bedingung zum Feld Z_NEU.
Damit sind Z_ALT (S) und Z_NEU (H) definiert. Für die Buchungsliste benötigen wir jedoch noch den Wert mit positiven Vorzeichen (in Excel würde hier als Formel ABS(Wert) für den absoluten Wert genommen werden.

c) Feld Z_WERT
Das lokale Feld hat folgende Eigenschaften:

Kurzbezeichnung Z_WERT
Feldbezeichnung Z_WERT
Überschrift Z_WERT

Hier hat das Feld die gleichen Eigenschaften wie das Feld WERT (entspricht CURR / Währung mit 15 Zeichen und 2 Dezimalstellen).

Als Formeln wird folgende komplexe Berechnung hinterlegt:

Bedingung
WERT < 0
Formel
- 1 * WERT

Bedingung
WERT > 0
Formel
1 * WERT

Sonst
WERT

Die so festgelegten lokalen Felder werden nun ebenfalls in der Grundliste mit als Listenfelder übergeben.

Nun kann diese Query als Grundlage für eine Umbuchung verwendet werden. Ähnlich wie bei der Tabellenauswertung wird hier
der Vorgang KAMV das Belastungs/Entlastungskennzeichen S sowie das Kalenderjahr ausgewählt.


Da jedoch eine Vielzahl von Buchungen vorhanden sind sollte diese Query noch bspw. in Access weiterverarbeitet werden.


 

3. Weiterverarbeitung der Query über KAMV in Access

Besonders wichtig ist hierbei, dass Buchungen die identische Sender und Empfänger haben Gruppiert und Summiert werden. Andernfalls haben wir ggf. wesentlich mehr Buchungssätze, als eigentlich erforderlich wäre.

Im Ergebnis haben wir nun folgende Query erhalten.

Be-/Entlastungskennzeichen (COEP-BEKNZ)
Geschäftsjahr (COEP-GJAHR)
Kostenartentyp (CSKB-KATYP)
Vorgang CO (COEP-VRGNG)
Belegnummer (COEP-BELNR)
Objektnummer (COEP-OBJNR)
Kostenart (COEP-KSTAR)
KOstenart Bezeichnung (CSKU-KTEXT)
Wert/KWähr (COEP-WKGBTR)
Partnerobjekt (COEP-PAROB)

Sowie unsere kundeneigene Felder
Z_ALT
Z_NEU
Z_WERT


In einer Datenbankanwendung (im Beispiel ACCESS) sind nun folgende Abfragen erforderlich.

001 Kostenart Neu
Aus der Grundliste der Query werden folgende Felder in die Abfrage übernommen:
Z_ALT
Kostenart
Wert/TWähr
Z_NEU

Hier sollte für Kostenarten des Typs 42 entsprechende Kostenarten des Typs 41 genommen werden.
Sofern es eine entsprechende Logik innerhalb der Kostenarten gibt (bspw. die Kostenarten Typ 42 beginnen mit 0815 und die korrespondierenden Kostenarten des Typs 41 beginnen mit 4711) kann hier eine passende Wenn Funktion genommen werden.

Beispiel:
Unter der Annahme, dass die Kostenarten achtstellig sind kann, sofern erforderlich die Kostenart wie folgt ermittelt werden.
NeuKA-1: Wenn(Links([Kostenart];4)="4711";"0815" & Rechts([Kostenart];4);0)

Gibt es daneben noch eine Kostenart die direkt ersetzt werden soll bspw. 55555590 durch 55555580 lautet die zweite Bedingen:
NeuKA-2: Wenn([Kostenart]="55555590";55555580;0)

Entsprechend können hier auch weitere "Austauschsfunktionen ermittelt werden.

Als letzter Punkt sollte auf dieser Kostenarten Bezug genommen werden, oder die ursprüngliche Kostenart genommen werden:

Z_Kostenart: Wenn([NeuKA-1]+[NeuKA-2]>0;[NeuKA-1]+[NeuKA-2];[Kostenart])


Zur Verdeutlichung noichmals die Hilfsfelder zur Ermittlung der "neuen" Kostenarten.

• NeuKA-1: Wenn(Links([Kostenart];4)="4711";"0815" & Rechts([Kostenart];4);0)
• NeuKA-2: Wenn([Kostenart]="55555590";55555580;0)
• Z_Kostenart: Wenn([NeuKA-1]+[NeuKA-2]>0;[NeuKA-1]+[NeuKA-2];[Kostenart])

002 KoSt oder IA
Sowohl in der Objektnummer als auch Partnerobjekt werden Kostenstellen als KS* und Innenaufträge als OR* ausgewiesen. Entsprechend ist das Feld Z_ALT sowie Z_NEU noch aufzuteilen ob es sich um eine Kostenstelle oder einen Innenauftrag handelt.

Hierbei wird unter Bezugnahme auf die Abfrage "001 Kostenart Neu" dieses wie folgt ermittelt.

Z_ALT aus 001 Kostenart_neu

ALT_Typ: Links([Z_ALT];2)
Sofern es sich um einen Auftrag handelt sind die ersten zwei Zeichen OR bei einer Kostenstelle KS

Unter der Annahme, dass sowohl Kostenstellen als auch Innenaufträge achtstellig sind (oder mit führender Null ausgewiesen werden, kann nun Z_ALT entsprechend auf die Felder Kost Alt (für sendende Kostenstelle) und Auftrag Alt (für sendenden Innenauftrag) ausgewertet werden-

Kost Alt: Wenn([ALT_Typ]="KS";Rechts([Z_ALT];8);"")

Aufrag Alt: Wenn([ALT_Typ]="OR";Rechts([Z_ALT];8);"")

Z_Kostenart aus 001 Kostenart_neu

Betrag: Wert/TWähr aus 001 Kostenart_neu


Genauso wie unter Z_ALT sowohl Kostenstellen als auch Innenaufträge ausgewiesen sein können, wird hier ebenfalls Z_NEU auf die Spalten Kost Neu und Auftrag Neu aufgeteilt.

Z_NEU aus 001 Kostenart_neu

NEU_Typ: Links([Z_NEU];2)

Kost Neu: Wenn([NEU_Typ]="KS";Rechts([Z_NEU];8);"")

Auftrag Neu: Wenn([NEU_Typ]="OR";Rechts([Z_NEU];8);"")

Als weiteres Feld wird noch die Sender-Empfänger-Beziehung ermittelt:
Beziehung: [ALT_Typ] & [NEU_Typ]
Somit wäre Auftrag an Auftrag bspw. OROR oder Kostenstelle an Auftrag KSOR.



003 Betrag in Summe
Für die Umbuchung sind nun alle Werte vorhanden, da aber Buchungen häufiger eine identische Sender-Empfänger Beziehung haben. Im Beispiel wird die Abteilung A wohl nicht nur eine Kopie im Jahr erhalten sondern häufiger Kopien nutzen ist es sinnvoll eine Gruppierung und Summe über die Werte zu erhalten.

Hierzu wird in dieser Abfrage wie folgt die vorherige Abfrage aufbereitet:
Die einzelnen Werte stammen aus der Abfrage "002 Kost oder IA"

Beziehung (Funktion Gruppierung)
Kost Alt (Funktion Gruppierung)
Auftrag Alt (Funktion Gruppierung)
Z_Kostenart (Funktion Gruppierung)
Betrag (Funktion Summe)
Kost Neu (Funktion Gruppierung)
Auftrag Neu (Funktion Gruppierung)

Somit sind dann alle Buchungen zusammengefasst.


Sollen die Buchungen per CATT eingespielt werden, kann es nützlich sein für die jeweilige Beziehung die Abfrrage 003 Betrag in Summe nochmals aufzuteilen.

Hierbei wird ein Suchkriterium über das Feld Beziehung gelegt, so dass hier insgesamt vier Abfragen mit Bezug auf "003 Betrag in Summe" erstellt werden:

010 Auftrag an Auftrag
Beziehung
Kriterien "OROR"
Auftrag Alt
Z_Kostenart
SummevonBetrag
Auftrag Neu

010 Auftrag an Kostenstelle
Beziehung
Kriterien "ORKS"
Auftrag Alt
Z_Kostenart
SummevonBetrag
Kost Neu

010 Kostenstelle an Auftrag
Beziehung
Kriterien "KSOR"
Kost Alt
Z_Kostenart
SummevonBetrag
Auftrag Neu

010 Kostenstelle an Kostenstelle
Beziehung
Kriterien "KSKS"
Kost Alt
Z_Kostenart
SummevonBetrag
Kost Neu

Weiterntwicklung der Grundlage (Query)

Grundsätzlich ist es natürlich überlegenswert die in der Datenbankanwendung erstellte Abfrage "002 KoSt oder IA" auch schon im Infoset durch Zusetzfelder oder aber in der Query zu erledigen. Hierzu müssten die Felder Objektnummer und Partnerobjekt auf Zusatzfelder *_KS und *_IA aufgeteilt werden. Sinnvollerweise würde dieses im Infoset erfolgen. Und ebenfalls, wie in der Datenbanklösung durch die Abfrage der ersten zeichen und Zuordnungen zum jeweiligen Feld. Dieses dürfte durch ein vergleichbares Coding wie im Artikel "Query über COEP, AUFK und FMFINCODE für Einzelposten Istkosten Innnenauftrag mit Stammdaten aus CO und PSM-FM sowie Spalten für Ertrag und Aufwand - Erster Teil Infoset als Datengrundlage" beschrieben möglich sein. Allerdings ist diese Query dann nicht ohne Weiteres innerhalb der Einrichtungen verteilbar, wenn unterschiedliche Längen von Kostenstellen und Innenauftragsnummern genutzt werden. Trotzdem könnte sich hier lokal, an der eigenen Einrichtungen, eine solche Anpassung tatsächlich lohnen da damit ein weiterer Schritt direkt aus SAP und nicht aus Excel oder Access erstellt wird...was ja durchaus auch einen eigenen Charme hat.
 

---

Hinweis:

Eine kurze Einführung in das Thema SAP Query habe ich im Artikel
"Grundlagen Kurzeinführung und Handbuch SAP Query" beschrieben und hoffe Ihnen hier eine Einführung ins Thema bieten zu können. Weitere Artikel zur Verarbeitung von Daten in MS Access sind unter Access zu finden.

---