Andreas Unkelbach
Logo Andreas Unkelbach Blog

Andreas Unkelbach Blog

ISSN 2701-6242

Artikel über Controlling und Berichtswesen mit SAP, insbesondere im Bereich des Hochschulcontrolling, aber auch zu anderen oft it-nahen Themen.


Werbung

Steuersoftware für das Steuerjahr 2023

Lexware TAXMAN 2024 (für das Steuerjahr 2023)

WISO steuer:Sparbuch 2024 (für Steuerjahr 2023)

WISO Steuer 2024 (für Steuerjahr 2023)


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


Montag, 14. Dezember 2020
06:14 Uhr

Weiterentwicklung SAP Query Einzelpostenliste Vorgang KAMV (manuelle Verrechnung) und KZPI (Gemeinkostenzuschläge) für Nacherfassung in Planversion

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

Für 19,95 € direkt bestellen

Oder als SAP Bibliothek-Flatrate *

Oder bei Amazon *
 
Vielleicht finden sich hier ja auch noch weitere Anregungen für den Aufbau eines Berichtswesen mit SAP nicht nur für CO im Buch.
 
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.




Hinweis: Aktuelle Buchempfehlungen besonders SAP Fachbücher sind unter Buchempfehlungen inklusive ausführlicher Rezenssionen und Bestellmöglichkeit zu finden.
SAP Weiterbildung
ein Angebot von Espresso Tutorials
SAP Weiterbildung - so wirksam wie eine gute Tasse Espresso

unkelbach.link/et.books/

unkelbach.link/et.reportpainter/

unkelbach.link/et.migrationscockpit/



Tags: KAMV Query

Keine Kommentare - - SAP

Artikel datenschutzfreundlich teilen

🌎 Facebook 🌎 Twitter 🌎 LinkedIn


Diesen Artikel zitieren:
Unkelbach, Andreas: »Weiterentwicklung SAP Query Einzelpostenliste Vorgang KAMV (manuelle Verrechnung) und KZPI (Gemeinkostenzuschläge) für Nacherfassung in Planversion« in Andreas Unkelbach Blog (ISSN: 2701-6242) vom 14.12.2020, Online-Publikation: https://www.andreas-unkelbach.de/blog/?go=show&id=1175 (Abgerufen am 29.3.2024)

Diesen und weitere Texte von finden Sie auf http://www.andreas-unkelbach.de


Keine Kommentare

Kommentieren?


Beim Versenden eines Kommentars wird mir ihre IP mitgeteilt. Diese wird jedoch nicht dauerhaft gespeichert; die angegebene E-Mail wird nicht veröffentlicht: beim Versenden als "Normaler Kommentar" ist die Angabe eines Namen erforderlich, gerne kann hier auch ein Pseudonyme oder anonyme Angaben gemacht werden (siehe auch Kommentare und Beiträge in der Datenschutzerklärung).

Eine Rückmeldung ist entweder per Schnellkommentar oder (weiter unten) als normalen Kommentar möglich. Eine persönliche Rückmeldung (gerne auch Fragen zum Thema) würde mich sehr freuen.

Schnellkommentar (Kurzes Feedback, ausführliche Kommentare bitte unten als normaler Kommentar)





Ich nutze zum Schutz vor Spam-Kommentaren (reine Werbeeinträge) eine Wortliste, so dass diese Kommentare nicht veröffentlicht werden. Sollte ihr Kommentar nicht direkt veröffentlicht werden, kann dieses an einen entsprechenden Filter liegen.

Im Zweifel besteht auch immer die Möglichkeit eine Mail zu schreiben oder die sozialen Medien zu nutzen. Meine Kontaktdaten finden Sie auf »Über mich« oder unter »Kontakt«. Ansonsten antworte ich tatsächlich sehr gerne auf Kommentare und freue mich auf einen spannenden Austausch.












* Amazon Partnerlink/Affiliatelinks/Werbelinks
Als Amazon-Partner verdiene ich an qualifizierten Käufen über Amazon.
Weitere Partnerschaften sind unter Onlineshop und unter Finanzierung und Transparenz aufgeführt. Hinauf






Logo Andreas-Unkelbach.de
Andreas Unkelbach Blog
ISSN 2701-6242

© 2004 - 2024 Andreas Unkelbach
Gießener Straße 75,35396 Gießen,Germany
andreas.unkelbach@posteo.de

UStID-Nr: DE348450326 - Kleinunternehmer im Sinne von § 19 Abs. 1 UStG

Andreas Unkelbach

Stichwortverzeichnis
(Tagcloud)


Aktuelle Infos (Abo)

Facebook Twitter XING

Linkedin Mastodon Bluesky

Amazon Autorenwelt Librarything

Buchempfehlung
Berichtswesen im SAP®-Controlling

19,95 € Amazon* Autorenwelt

Espresso Tutorials

unkelbach.link/et.reportpainter/

unkelbach.link/et.migrationscockpit/

Privates

Kaffeekasse 📖 Wunschliste