Der vorliegende Blog enthält von mir im Laufe meiner beruflichen Tätigkeit als SAP-Berater zusammengetragene Informationen / Beispiel-Codings zum Themenkreis SAP, speziell FI/CO.
Veröffentlicht am 19. Dezember 2012
von sapmandoo
inCO
Bei einem Projekt gab es die Anforderung, die eingelesen Abverkaufsdaten vom POS ins SAP zu laden, aber bei den daraus entstehenden (POS-)Fakturen keinen FI-Beleg zu erzeugen. Allerdings sollte die Fortschreibung ins CO-PA nicht unterbunden werden.
Hierzu wurde folgendes Coding in der SAP-Erweiterung SDVFX008 (Funktionsexit EXIT_SAPLV60B_008, Include ZXVVFU08) implementiert (CMOD):
...
data: l_tabix type sytabix,
ls_accit like line of xaccit.
* Kill FI, long live CO-PA!!!
* Table XACCIT contains lines for FI and CO-PA document
* --> Remove lines for FI-doc only!
* Caution: for certain cases only
check ... <> ... AND ...
loop at xaccit into ls_accit.
l_tabix = sy-tabix.
if ls_accit-kstat = space. "line of FI doc
* delete line in item table
delete xaccit index l_tabix.
* delete corresponding entry in amount table
delete xacccr index l_tabix.
endif.
endloop.
Diese Aktion darf natürlich nur in den relevanten Konstellationen durchgeführt werden, d.h. es ist auf eine hinreichend scharfe Abgrenzung zum übrigen Belegaufkommen zu achten!
Veröffentlicht am 21. Februar 2012
von sapmandoo
inSAP Reports
Bei der Erstellung von Report Painter bzw. Report-Writer-Berichten wird eine sog. Berichtstabelle verwendet, die je nach Arbeitsgebiet variiert. Häufig verwendete Berichtstabellen sind bspw.:
In diesen Tabellen bzw. Strukturen sind von SAP vordefinierte Merkmale und Basiskennzahlen enthalten, die aber bei Bedarf erweitert werden können. Hierzu sind ein gewisses Verständnis der zugrundeliegenden Datenstrukturen sowie ABAP/4-Programmierkenntnisse erforderlich.
Die Definition der Berichtstabellen sowie der entsprechenden Datenversorungsroutinen sind in den Tabellen T804* hinterlegt, die Pflege erfolgt über die Transaktion GRCT.
Es werden die ausgelieferten Berichtstabellen angezeigt. Im Detailbild der ersten Pflegeebene ist u.a. eine sog. Zusatzstruktur angegeben, in der wiederum ein Customer-Include enthalten ist, in dem bei Bedarf eigene Felder hinzugefügt werden können.
Folgendes Beispiel soll dies veranschaulichen:
In der Berichtstabelle CCSS soll das Merkmal "Kostenstellenverantwortlicher" eingefügt werden. Das Feld ist im Kostenstellenstamm enthalten (CSKS-VERAK) und wird bei der Datenselektion des Berichts aus dem Kostenstellenstammsatz nachgelesen.
Feld in Zusatzstruktur ergänzen
Zur Berichtstabelle CCSS ist die Zusatzstruktur CCR1S zugeordnet. In ihr ist der Customer-Include CI_CC1S enthalten. In diesen fügen wir unser neues Feld hinzu (SE11). Dies sollte idealerweise im Kundennamensraum erfolgen, da ja nicht auszuschließen ist, dass SAP in kommenden Releases die Berichtstabellen um neue Felder erweitert. Für das Beispiel verwenden wir ZZ_VERAK des Typs VERAK.
Füllroutine implementieren und zuweisen
Die Füllroutine wird in dem zur Berichtstabelle zugeordneten Formpool hinterlegt.
Zur Tabelle CCSS ist dies SAPFK21R. Dieses Programm enthält bereits Includes für kundeneigene Routinen (u.a. FK21REZZ). Da es sich trotzdem um einen Teil des SAP-Standard handelt, muss das kundeneigene Coding entweder im Rahmen eines Enhancements implementiert werden oder man benötigt den entsprechenden SSCR-Schlüssel für das Objekt und verwendet den Modifikationsassistenten.
Die Füllroutine wird unter "spezielle Merkmale" dem System bekannt gemacht.
Die Füllroutinen haben folgende Übergabeparameter:
--> TAB
Aktuelle Tabelle aus der gelesen wird
--> DEF_FLD
Wert des bestimmendes Feld (optional)
--> CNV_FLD1
Wert des 1. Konvertierungsparameters (optional)
--> CNV_FLD2
Wert des 2. Konvertierungsparameters (optional)
--> CNV_FLD3
Wert des 3. Konvertierungsparameters (optional)
<-- FLD
Wert des zu füllenden Feldes
Beispiel-Coding für Füllroutine
FORM Z21_FILL_VERAK USING TABLE LIKE T804E-TAB KOKRS LIKE CCR1S-KOKRS VERAK LIKE CCR1S-ZZ_VERAK.
DATA: L_KOSTL LIKE CSKS-KOSTL.
CASE TABLE. WHEN 'COSP'. IF COSP-OBJNR(2) = 'KS'. L_KOSTL = COSP-OBJNR+6(10). ENDIF.
WHEN 'COSS'. IF COSS-OBJNR(2) = 'KS'. L_KOSTL = COSS-OBJNR+6(10). ENDIF.
WHEN 'COEP'. IF COEP-OBJNR(2) = 'KS'. L_KOSTL = COEP-OBJNR+6(10). ENDIF.
WHEN 'COEJ'. IF COEJ-OBJNR(2) = 'KS'. L_KOSTL = COEJ-OBJNR+6(10). ENDIF.
WHEN OTHERS. CLEAR L_KOSTL. EXIT. ENDCASE.
Check l_kostl ne space.
Select single verak from csks into verak
Where kokrs = kokrs
And kostl = l_kostl
And datbi >= O_SEL_DATE. ”BerichtsVARIABLE
If sy-subrc ne 0.
Clear verak.
Endif. ENDFORM.
Im Ergebnis steht nun das Merkmal "Kostenstellenverantwortlicher" wie gewohnt im Kontext des CO-Reportings zur Verfügung und kann nun im Report Painter bzw. Report Writer Umfeld verwendet werden.
Veröffentlicht am 27. September 2011
von sapmandoo
inCO
Mit dem nachfolgenden Report können Sie Recherche-Berichte (inkl. Formulare) von einem Ergebnisbereich in einen anderen kopieren, wobei diese natürlich strukturell kompatibel sein müssen. So ganz ausgereift ist die Sache noch nicht (siehe Abschnitt 'Einschränkungen' im Report-Header) aber besser als nix.
*&---------------------------------------------------------------------* *& Report YRKE_COPY_REPORT *& Version 0.1 *&---------------------------------------------------------------------* *& Kopieren von Reports zwischen verschiedenen Ergebnisbereichen *& Achtung: Ergebnisbereiche dürfen sich natürlich nur vom Namen her *& unterscheiden. Wenn die Strukturen nicht kompatibel sind, macht die *& Nummer hier absolut keinen Sinn!!!! *& *& Einschränkungen Version 0.1: *& ---------------------------- *& - Formulartexte werden nicht mitkopiert --> manuell nachpflegen *& - Formelprioritäten müssen im Formular manuell nachbearb. werden *&---------------------------------------------------------------------*
REPORT yrke_copy_report. TABLES: tkeb1, tka01.
DATA: i_tkeb1 TYPETABLEOF tkeb1 WITHHEADERLINE. DATA: l_tabname_wild LIKE tkeb1-tabname, l_tabname LIKE tkeb1-tabname.
PARAMETERS: pa_serkr LIKE tka01-erkrs OBLIGATORY, pa_terkr LIKE tka01-erkrs OBLIGATORY. SELECT-OPTIONS: so_repid FOR tkeb1-repid. PARAMETERS: pa_test ASCHECKBOXDEFAULT'X'.
AT SELECTION-SCREEN. IF pa_serkr = pa_terkr. MESSAGE e600(fr) WITH'Bitte Quell- und Zielergebnisbereich' 'unterschiedlich wählen'. ENDIF.
START-OF-SELECTION.
* Selektion aller Berichte im Quell-Ergebnisbereich CONCATENATE'___' pa_serkr INTO l_tabname_wild. SELECT * FROM tkeb1 INTOTABLE i_tkeb1 WHERE applclass = 'KE' AND subclass = '01' AND tabname LIKE l_tabname_wild AND repid IN so_repid.
Einige ältere BAPIs liefern Ihre Nachrichten noch in der Struktur BAPIRETURN zurück. In diesem Falle kann man diese zuvor in die Struktur BAPIRET2 überführen.
Bsp:
DATA: lt_return TYPETABLEOF bapireturn, lt_bapiret2 type table of bapiret2.
Veröffentlicht am 23. März 2011
von sapmandoo
inSD
In den Standardkalkulationsschemata des Vertriebes wird als Konditionsart zum Ausweis der Ausgangssteuer MWST verwendet (Ausnahme POS-Fakturen, s. weiter unten).
Customizing
Der Konditionsart MWST ist im SAP-Auslieferungszustand die gleichnamige Zugriffsfolge zugeordnet:
IMG: Vertrieb> Grundfunktionen> Preisfindung> Steuerung der Preisfindung> Konditionsarten definieren
Die Zugriffsfolge MWST beinhaltet im SAP-Standard folgende Zugriffe:
Lfd.Nr.
Tab.
Bezeichnung
Bedingung
Exklusiv
10
002
Steuern Inland
7
X
20
011
Steuern Export
8
Die Bedingung 7 prüft dabei, ob es sich bei dem vorliegenden Geschäft um ein Inlandsgeschäft im Sinne des UStG handelt. Dies ist offensichtlich dann gegeben, wenn Empfängerland (Warenempfänger[!]) und das Land des Lieferwerks übereinstimmen. Ein Inlandsgeschäft ist aber gemäß der Bedingung auch dann gegeben, wenn beide beteiligten Länder der EU angehören und der Empfänger kein Unternehmen ist (B2C-Geschäft). Dies wird vom System daran identifiziert, dass im entsprechenden Kundenstammsatz keine Umsatzsteuer-Identnummer eingetragen ist. In allen übrigen Fällen handelt es sich um ein Exportgeschäft, was durch die Bedingung 8 nochmals verifiziert wird.
Die Tabelle 011 beinhaltet folgende Merkmale:
Feld
Bezeichnung
Erläuterung / Werte
Customizing
ALAND
Land
Leitet sich aus dem liefernden Betrieb ab (s. Tab. T005)
./.
LAND1
Empfangsland
Land aus dem Stammsatz des Warenempfängers
./.
TAXK1
Steuerklassifi.-Kd
0 = steuerbefreit
1 = steuerplichtig
Die Pflege erfolgt in der Vetriebssicht des Debitorenstammsatzes
Vertrieb> Grundfunktionen> Steuern> Steuerrelevanz der Stammsätze definieren> Steuern: Debitoren
TAXM1
Steuerklassifi. Art
0 = keine Steuer
1 = volle Steuer
2 = halbe Steuer
ggf. weitere, z.B. Mischsteuersätze (Landwirtschaft)
Die Zuordnung erfolgt im Artikelstammsatz (Grunddatensicht)
Vertrieb> Grundfunktionen> Steuern> Steuerrelevanz der Stammsätze definieren> Steuern: Artikel
Steuerrelevante Indikatoren für Vertriebsbelege
Die Tabelle 002 (Steuern Inland) ist eine Teilmenge der oben stehenden Tabelle und enthält nur die Steuerklassifikationen Artikel und Debitor.
Konditionspflege
Die Werte zur Konditionsart MWST werden in der Anwendung mithilfe der Transaktionen VK31 bzw. VK32 (-> Steuern -> MWST/ATX1) hinterlegt.
Beispiel:
Inland:
St.Klass. Debitor
St.Klass. Artikel
Steuer-Kz.
Bezeichnung
0
0
A0
Ausgangssteuer 0%
0
1
A0
Ausgangssteuer 0%
0
2
A0
Ausgangssteuer 0%
1
0
A0
Ausgangssteuer 0%
1
1
A1
Ausgangssteuer Inland volle Steuer
1
2
A2
Ausgangssteuer Inland halbe Steuer
Beispieleinträge zur Kondition MWST (Steuern Inland)
Export:
Land
Empf.-land
St.Klass. Debitor
St.Klass. Artikel
Steuer-Kz.
Bezeichnung
DE
AT
0
0
A6
MwSt 0% EG-Lieferung
DE
AT
0
1
A6
DE
AT
0
2
A6
DE
AT
1
0
A6
DE
AT
1
1
A6
DE
AT
1
2
A6
DE
CH
0
0
A0
MwSt 0% - Kein Steuervorgang
DE
CH
0
1
A0
DE
CH
0
2
A0
DE
CH
1
0
A0
DE
CH
1
1
A9
MwSt 0% Export Drittland
DE
CH
1
2
A9
MwSt 0% Export Drittland
Beispieleinträge zur Kondition MWST (Steuern Export)
Hinweise: Da mit jeder gesetzlichen Änderung des Steuersatzes neue Steuerschlüssel angelegt werden müssen, sind die aktuell gültigen Steuerkennzeichen ggf. bei der entsprechenden Fachabteilung zu erfragen. Nicht in jedem Land gibt es die Unterscheidung zwischen ermäßigtem und vollem Steuersatz (z.B. Belgien).
Besonderheiten bei POS-Fakturen
Im Standardkalkulationsschema POS000 wird als Steuerkondition die Konditionsart MWSI verwendet. Es ist im Customizing zu prüfen, ob ihr auch die Zugriffsfolge MWSI zugeordnet ist. Diese behandelt sämtliche Verkäufe als Inlandsgeschäfte, was auch korrekt ist, da die Ware unabhängig von der Herkunft des Kunden mit der Umsatzsteuer des jeweiligen Landes der Filiale zu belegen ist. Die Steuerrückerstattung für ausländische Kunden (Stichwort: ‚Tax-Free’) ist ein vom POS-Abverkauf gänzlich entkoppelter Vorgang. Dies kann dann problematisch werden, wenn die Verbuchung über den anonymen Debitor vorgenommen und dieser länderübergreifend verwendet wird, da das ‚Land’ ein Feld in den mandantenabhängigen Daten des Debitorenstamms ist.
Weitere Details finden sich im Beratungshinweis 827449.
Veröffentlicht am 23. März 2011
von sapmandoo
inMM
Steuerfindung in der Bestellung
Der Bestellung selbst liegt kein steuerpflichtiger Vorgang im Sinne des UStG zugrunde, jedoch fußen etliche Folgebelege auf ihr, die durchaus steuerliche Relevanz haben, z.B. die Rechnungsbelege aus der logistischen Rechnungsprüfung / ERS-Abrechnung, nachträgliche Vergütung usw. Die erwähnten Folgebelege gründen ihrerseits den Steuerausweis auf dem zuvor in der Bestellung ermittelten Steuerkennzeichen. Im SAP-Standard (Einkaufskalkulationsschema RM0000) ist keine Steuerkonditionsart vorhanden, abgesehen von NAVS (‚nicht abzugsfähige Vorsteuer’), die ja eben durch ihre Eigenschaft der ‚Nichtabzugsfähigkeit’ den Einstandspreis einer Ware tatsächlich erhöht. Details zur Steuerfindung in Bestellbelegen finden sich im Beratungshinweis 501054. Unter Pkt 1. im genannten Hinweis finden sich alle Möglichkeiten, das Steuerkennzeichen innerhalb der Bestellung zu ermitteln. U.a. lässt es sich mithilfe von Konditionssätzen automatisiert bestimmen. Hierzu werden geeignete Konditionssätze zur Konditionsart NAVS hinterlegt.
Customizing
Der Konditionsart NAVS ist im Auslieferungszustand die Zugriffsfolge 0003 zugeordnet:
Konditionsart NAVS Nicht abz. Vorsteuer Zugriffsfolge 0003 Steuerkennzeichen
Kond.Klasse D Steuern Vorzeichen positiv und negativ
In aller Regel lassen sich sämtliche steuerfindungsrelevanten Konstellationen mithilfe der Tabelle 86 (s.o.) darstellen. Diese beinhaltet folgende Merkmale:
Feld
Bezeichnung
Erläuterung / Werte
Customizing
LAND1
Empfangsland
Leitet sich aus bestellendem Betrieb ab (s. Tab. T005)
2 = halbe Steuer (z.B. Bücher, neuerdings auch Hotelübernachtungen J)
Materialwirtschaftà Einkaufà Steuernà Steuerindikator für Artikel einstellen
Siehe nachf. Kap.
TAXIW
Steuerind. Betrieb
0 = steuerbefreit
1 = steuerpflichtig
Materialwirtschaftà Einkaufà Steuernà Steuerindikator für Betrieb einstellen / …Steuerindikatoren für Betriebe zuordnen
TAXIL
Steuerind. Import
Der Wert wird vom System in der Bestellung anhand der Korrelation ‚Empfangsland / Lieferland (Land des Lieferanten)’ gesetzt:
0 = kein Import -> Empfangsland = Lieferland
1 = Import -> Lieferland ungleich Empfängerland und mindestens eines der beiden beteiligten Länder ist kein EU-Land[1]
2 = EU-Import -> Lieferland ungleich Empfängerland, wobei beide beteiligten Länder der EU angehören.
./.
Steuerrelevante Indikatoren für Bestellung
Zuordnung Artikel -> Steuerindikator
Die Zuordnung eines Artikels zum entsprechenden Steuerindikator wird in der Tabelle MLAN gespeichert. Diese Tabelle hat neben der Artikelnummer lediglich das Lieferland als Schlüssel, wird aber im Rahmen der Artikelstammpflege (Transaktion MM42) bei den werksabhängigen Daten hinterlegt. Zur vollständigen Pflege in den relevanten Ländern genügt es somit, den Steuerindikator in einer Filiale eines Landes einzutragen.
Konditionspflege
Die Werte zur Konditionsart NAVS werden in der Anwendung mithilfe der Transaktionen MEK1 bzw. MEK2 hinterlegt.
Hinweise: Da mit jeder gesetzlichen Änderung des Steuersatzes neue Steuerschlüssel angelegt werden müssen, sind die aktuell gültigen Steuerkennzeichen ggf. bei der entsprechenden Fachabteilung zu erfragen. Nicht in jedem Land gibt es die Unterscheidung zwischen ermäßigtem und vollem Steuersatz (z.B. Belgien).
[1] Die Kennzeichnung, ob ein Land zur EU gehört, findet sich in der Ländertabelle T005, Feld XEGLD
Veröffentlicht am 23. März 2011
von sapmandoo
inFI
Sofern ein warenwirtschaftlicher Prozess Niederschlag in den SAP-Rechnungswesenmodulen findet, erfolgt die Integration mithilfe des RW-Interfaces. Im technischen Kern besteht die RW-Schnittstelle aus folgenden Bestandteilen:
Systemtabelle TRWPR
Interne Übergabestrukturen und -tabellen ACCHD, ACCIT, ACCTX, …
Funktionsbaustein AC_DOCUMENT_CREATE
Schematische Darstellung der RW-Schnittstelle
Im Rahmen der Verbuchung der warenwirtschaftlichen Belege werden die Strukturen bzw. Tabellen ACCHD, ACCIT etc. aufgebaut und in einem übergeordneten Hauptspeicherbereich abgelegt. Das RW-Interface in Form des Funktionsbausteins AC_DOCUMENT_CREATE ‚loopt’ über die Tabelle TRWPR und ruft nacheinander die dort zum jeweiligen Rechnungswesenmodul hinterlegten Verbuchungsbausteine auf. Diese bedienen sich der zuvor im Memory abgelegten ACC*-Strukturen und generieren daraus ihre jeweiligen Belege.
Hinweis: Im Rahmen der Verbuchung werden im SAP-Standard die ACC*-Tabellen persistent abgespeichert (DB-Tabellen ACCTHD, ACCTIT usw.). Diese können je nach Durchsatz in der RW-Schnittstelle sehr schnell und umfangreich anwachsen. Diese Ursprungsbeleginformationen werden für den Fall gesichert, dass im Nachgang neue Rechnungswesenmodule aktiviert werden und eine Nachbuchung der Belege erfolgen muss. Detaillierte Informationen hierzu finden sich im Beratungshinweis 48009. Hierin ist auch eine Möglichkeit aufgeführt, die Fortschreibung der genannten Tabellen generell zu unterbinden bzw. die Tabelleninhalte zu archivieren, falls das Wachstum der Tabellen performancekritsche Ausmaße annimmt.
Das Design der RW-Schnittstelle ist im Standard so, dass pro Position im Ursprungsbeleg (z.B. Faktura oder Artikelbeleg) jeweils ein Buchungssatz im FI erzeugt wird. Dies resultiert daraus, dass im FI-Beleg eine Vielzahl der Informationen aus dem Ursprungsbeleg übernommen wird (bspw. die Artikelnummer aus den zugrunde liegenden Artikelbelegen). Bei der Buchung von Belegen über die RW-Schnittstelle (aus SD, MM oder anderen Applikationen) entstehen somit im FI-Beleg Positionen, die in allen oder fast allen Feldern identisch sind. Dies kann auch eine Ursache für die Fehlermeldung F5/727 ('Maximale Anzahl von Positionen im FI erreicht') sein, die dann erscheint, wenn die maximale Anzahl von 999 Positionen[1] im FI-Beleg erreicht wird.
Beispiel:
Preisänderung (Abschrift)
Artikelbeleg (vereinfacht)
FI-Beleg (vereinfacht)
Pos. Artikel Betrieb Preis (alt) Preis (neu)
Pos. S/H Konto Betrag
001 4711 1000 1,-- 0,50
001 S Aufw.XYZ 0,50
002 4712 1000 2,-- 1,--
002 H Bestand 0,50
003 S Aufw.XYZ 1,--
004 H Bestand 1,--
Belegfortschreibung im FIohneBelegverdichtung
Über die Funktion Belegverdichtung im SAP kann das System angewiesen werden, bestimmte Feldinhalte eben nicht aus dem Ursprungsbeleg in den FI-Beleg zu übernehmen und damit eine Zusammenfassung von Belegpositionen in der Finanzbuchhaltung zu ermöglichen. Wenn also üblicherweise die Artikelnummer aus dem FI-Beleg entfernt wird, können die im obigen Beispiel vier Belegpositionen zu zweien verdichtet werden:
Artikelbeleg (vereinfacht)
FI-Beleg (vereinfacht)
Pos. Artikel Betrieb Preis (alt) Preis (neu)
Pos. S/H Konto Betrag
001 4711 1000 1,-- 0,50
001 S Aufw.XYZ 1,50
001 4712 1000 2,-- 1,--
002 H Bestand 1,50
Belegfortschreibung im FImitBelegverdichtung über Artikelnummer
Zwar geht damit die Information ‚Artikel’ im FI-Beleg verloren, jedoch kann diese aus dem zugrunde liegenden Artikelbeleg einfach besorgt werden. Auf die gleiche Weise kann man auch mit anderen Feldern im Beleg verfahren, z. B. ‚Menge’.
Customizing
Über die Transaktion OBCY werden pro Referenzvorgang[2] die Felder definiert, die nicht in den FI-Beleg übernommen werden. Die relevanten Referenzvorgänge, d.h. diejenigen, die das meiste Einsparungspotenzial an Belegzeilen beinhalten, sind:
MKPF Artikelbelege
RMRP Belege aus der log. Rechnungsprüfung
VBRK Faktura
Um bspw. die Übernahme der Artikelnummer beim Referenzvorgang MKPF zu unterbinden, muss das entsprechende Feld im FI-Beleg (Tabelle BSEG) spezifiziert werden:
Referenzvorgang MKPF
Bezeichnung Artikelbeleg
Tabellenname Feldname
BSEG MATNR
Customizing Belegverdichtung (Transaktion OBCY)
Im SAP-Hinweis 36353 sind häufig verwendete Einstellungen für die oben genannten Referenzvorgänge enthalten:
Applikation
AWTYP
Tabelle
Feldname
SD
VBRK
BSEG
MATNR
Fakturierung
MEINS
MENGE
PAOBJNR
POSN2
VBEL2
WERKS
MM
MKPF
BSEG
BPMNG
Bestandsführung
BPRME
ERFME
ERFMG
MATNR
MEINS
MENGE
PAOBJNR
POSN2
WERKS
BWTAR
MM
RMRP
BSEG
BPMNG
Logistik-
BPRME
Rechnungsprüfung
ERFME
ERFMG
MATNR
MEINS
MENGE
PAOBJNR
WERKS
Empfohlene Einstellungen zur Belegverdichtung gem. SAP-Hinweis 36353
Sonderfall Verdichtung von FI-Belegen mit Bestellbezug
Im SAP-Standard kann über die Felder Bestellnummer (EBELN) und Bestellposition (EBELP) NICHT verdichtet werden. Sie werden sowohl bei dem Wareneingang mit Bezug auf die Bestellung (MB01) als auch bei der Rechnungsprüfung im FI-Beleg mitkontiert und verhindern hier die Verdichtung des FI-Belegs. Dies ermöglicht, das WE/RE-Verrechnungskonto auf der Ebene der Bestellposition auszugleichen. Dadurch kann es jedoch bei umfangreichen Wareneingangsbuchungen bzw. Rechnungseingängen zu Problemen, d.h. zur Überschreitung der maximal möglichen Anzahl von Belegpositionen (999) kommen. Im SAP-Hinweis 77161 ist eine Möglichkeit aufgezeigt, wie diese Art von Belegen wenigstens über die Belegposition (EBELP) verdichtet werden können. In neueren Releases können FI-Belege, die bspw. aus Wareneingangsbuchungen herrühren, automatisch gesplittet werden, wenn der Ursprungsbeleg zu groß ist.
Simulation/Analyse
Mithilfe des Analyseprogramms RSUMSIFI kann die Belegverdichtung vor Aktivierung simuliert werden, um bspw. zu evaluieren, ob sich die Einrichtung der Belegverdichtung ‚lohnt’. Details hierzu finden sich im Hinweis 310837. Gewisse ABAP-Kenntnisse vorausgesetzt, eignet sich der Report zudem als Analysetool für Fragestellungen wie: ‚warum wurde der Beleg xxx trotz aktiver Belegverdichtung nicht komprimiert?’. Setzen Sie hierzu einfach einen Break-Point in der Routine ‚COMPRESS_BSEG’ und vergleichen Sie nach Durchlauf im Debugger die Tabellen t_bseg und t_bseg_compr. Sie können hier leicht erkennen, welche nicht-initialen Beleginhalte die Verdichtung verhindern.
Besonderheiten
Verdichtung von FI-Belgen aus internen Fakturen (Szenario ‚CC-Nachschub’)
Beim genannten Szenario reichen die im Hinweis 36353 genannten Felder zum Vorgang VBRK (s.o.) nicht aus, um die FI-Belege aus den internen Fakturen zu verdichten, da hierbei die Bestellnummer und-position der zugrunde liegenden UB in die FI-Belegpositionen übertragen werden. Diese verhindern eine Verdichtung des Beleges im vorgenannten Sinne. In diesem Fall müssen zum Vorgang VBRK in leichter Abwandlung des Hinweises 77161 zusätzlich die Felder BSEG-EBELN und BSEG-EBELP aufgenommen werden. Dies ist ohne weiteres möglich, da bei der Verbuchung der Faktura das WE/RE-Konto nicht berührt wird und somit die Einschränkungen des Hinweises 77161 nicht greifen.
Einsatz der Ergebnis- und Marktsegmentrechnung (CO-PA)
Bei aktivem CO-PA ist unter bestimmten Umständen eine Belegverdichtung über Materialbelege (Referenzvorgang MKPF) nicht möglich. Dies ist z.B. dann der Fall, wenn Abschriften oder Inventurdifferenzen ins CO-PA durchgebucht (man spricht auch von ‚…ins Ergebnis abgerechnet’) werden sollen. Der CO-PA-Beleg wird mit Ausnahme der Faktura ausschließlich aus dem FI-Beleg befüllt. Wenn also mithilfe der Belegverdichtung bspw. die Artikelnummer aus den FI-Belegen entfernt wird, ist eine Fortschreibung der Artikelnummer und den daraus abgeleiteten Merkmalen (Warengruppe etc.) im CO-PA unmöglich. Dem kann zum einen begegnet werden, in dem organisatorisch bzw. technisch dafür gesorgt wird, dass Artikelbelege einen bestimmten Umfang (ca. 450 Pos.) nicht überschreiten (vgl. Hinweis 1411253 - Warenbewegungen aus EWM) oder zum anderen ein automatisierter Belegsplit im FI erfolgt. Letzteres ist jedoch nur in neueren Releases[3] möglich. Eine Vorabkorrektur ist ab Rel. 6.03 verfügbar. Details hierzu finden sich im Hinweis 1353827.
Belegsplit bei log. Eingangsrechnungen (MIRO)
Im Hinweis 1497092 findet sich eine Lösung, wie sich - unter bestimmten Voraussetzungen - ein Belegsplit im Rahmen der log. Rechnungsprüfung implementieren lässt, so dass eine Belegverdichtung des Vorgangs RMRP (s.o.) nicht mehr zwingend erforderlich ist.
[1] Die Einschränkung ist historisch dem numerischen Feld ‚Buchungszeile’ (BUZEI) in der BSEG geschuldet, dessen Domäne mit Typ NUMC der Länge 3 definiert ist.
[2] Der Referenzvorgang ist eine betriebswirtschaftliche Klassifizierung von Belegen im SAP-System. Dieser wird durch eine 4-5stellige, eindeutige Zeichenfolge qualifiziert.
Veröffentlicht am 22. Februar 2011
von sapmandoo
inFI
Validierungen und Substitutionen sind mächtige Werkzeuge im FI/CO-Umfeld und können so manches Ungemach vom Buchungsstoff abwenden bzw. das Leben der Buchhalter/Controller erleichtern. Typische Anwendungsfälle sind z.B.:
- Profitcenter-Substution (s.u.)
- Dummy-Funktionsbereich setzen, wenn die Funktionsbereichsableitung bis dahin kein Ergebnis brachte
- Validierung, ob für bestimmte Konten eine Partnerkontierung abgeleitet werden konnte (s.u.)
- Validierung, dass Investitionsaufträge nur mit bestimmten Kostenarten/Konten bebucht werden dürfen (vgl. link)
- und, und und...
Die Validierung greift auch bei der Vorerfassung (Details s. HW 158739), während die Substitution erst beim Buchen wirkt.
Interessante SAP-Hinweise
842318 - umfangreiches FAQ zu diesem Themenkomplex
42615 - die Mutter aller Hinweise zum Thema Substitutionen im FI
438076 - (gutes) Beispiel für eine Substitution zum Zeitpunkt 3 (kompletter Beleg)
386896 - Substitution zum Zeitpunkt 3 (RW-Interface SD/MM)
48121 - Verwendung von Userexits in Validierungen und Substitutionen
158739 - Validierung bei der Belegvorerfassung im FI
Generieren von Validierungen und Substitutionen
Unter bestimmen Umständen ist eine Nachgenerierung des Validierungs- bzw. Substitutionscodings erforderlich. Dies erfolgt mithilfe des Reports RGUGBR00.
Pflege der Tab. GB01
Lt. SAP-Hinweis 42615 sind Änderungen an der Tabelle GB01 Modifikationen, deshalb gibt es auch keinen offiziellen Pflegeview. In neueren Releases gibt es aber einen 'inoffiziellen': VWTYGB01 (Pflege über Transaktion SM30).
Neuer Substitutions-/Validierungsexit
1. Prüfen, ob in GCX2 bereits zum Arbeitsgebiet GBLS (Substitution) bzw. GBLR (Validierung) ein Z-Programm zugewiesen ist. Falls nicht, die Standardformpools RGGBS000 bzw. RGGBR000 in den Kundennamensraum kopieren und in der GCX2 dem entsprechenden Arbeitsgebiet zuweisen.
2. Exit-Routine gemäß untenstehendem Muster ausprogrammieren. Zusätzliche Infos (u.a. auch zur Verwendung von Parametern) finden sich im SAP Hinweis 48121.
form u900 using is_booldata type GB002_015.
* insert your substitution logic here
* document header: is_booldata-bkpf
* document lines: is_booldata-bseg
*!!!!! change only 'allowed' fields according to table GB01 !!!!*
* ...
endform.
Konkrete Anwendungsbeispiele
Profitcenter-Substitution
Mithilfe der Profitcenter-Substitution kann das zu kontierende Profitcenter in Abhängigkeit von bestimmten Informationen aus dem Ursprungsbeleg gefunden werden. Die Implementierung der entsprechenden Ableitungsregeln erfolgt im IMG unter Controlling> Profit-Center-Rechnung> Zuordnungen von Kontierungsobjekten zu Profitcentern> Kundenaufträge> Substitutionen Kundenaufträge bzw. Transaktion 0KEM
Pro Substitutionsschritt kann eine Voraussetzung (Bedingung) angegeben und das Profitcenter auf folgende Weise zurückgegeben werden:
Konstanter Wert
Feld an Feld-Zuweisung (z.B. Profitcenter = Betrieb)
Exit
Hierbei stehen die Felder der Struktur PCASUB sowie div. Systemfelder (z.B. SY-TCODE = rufender Transaktionscode) zur Verfügung.
Beispiel:
Das Profitcenter soll aus der Verkäufergruppe des Vertriebsbelegs abgeleitet und jeweils als ein konstanter Wert zurückgeliefert werden. Hierbei muss für jede auszusteuernde Verkäufergruppe über den ‚Formula Builder’ ein Substitutionsschritt angelegt werden, der als Voraussetzung die jeweilige Abfrage auf die Verkäufergruppe(n) beinhaltet (PCASUB-VKGRP = ‚<Wert>’) und das entsprechende Profitcenter zuordnet (Abschnitt ‚Substitutionen’).
Substitutionsexits
Reichen die Funktionen des Formulabuilders nicht aus oder müssen andere Daten hinzu gelesen werden, kann die Substitution mithilfe eines Exits vorgenommen werden. Folgende Schritte sind dazu nötig:
Kopieren des SAP-Formpools RGGBS000 in den Kundennamensraum (z.B. ZGGBS000)
Anmelden des kundeneigenen Formpools im Arbeitsgebiet GBLS (Transaktion GCX2)
ArbGb
Ex.prog.
Arbeitsgebiet
GBLR
RGGBR000
Val/Sub:Exits for Rules
GBLS
ZGGBS000
Val/Sub:Exits for Substitution
GBRU
RGLVU000
Rollup: User-Exits
…
…
…
Transaktion GXC2 - Zuweisung Formpool
Implementierung des Substitutionsexits
Ein Beispiel zur Implementierung eines Substitutionsexits im Rahmen der Profitcenter-Substitution findet sich in der zugehörigen Korrektur des Beratungshinweises 173798. Zudem sollten folgende Punkte bei der Entwicklung des Substitutionsexits beachtet werden:
Die (kundeneigenen) Substitutionsroutinen tragen eine 4stellige Bezeichnung. Diese kann wahlweise mit Z oder Y (z.B. Zxxx) beginnen oder im Bereich U900-U999 angesiedelt sein. Diese Routinen müssen in der Form get_exit_tables am System angemeldet werden (s. Beispielcoding im o.g. Hinweis)
Die Rückgabe des ermittelten Profitcenters erfolgt immer im Feld PRCTR der Übergabestruktur PCASUB.
Die Felder der Struktur PCASUB werden durch den Ursprungsbeleg so weit wie möglich gefüllt. Zusätzlich benötigte Dateninhalte müssen ggf. von der Datenbank nachgelesen oder mittels ‚Dirty Assign’ aus den rufenden Programmen geholt werden.
Beim Szenario ‚Buchungskreisübergreifender Verkauf’ wird die Substitution zweimal durchlaufen, weil einmal das Profitcenter für die Faktura an den Endkunden und einmal für die interneVerrechnung ermittelt wird. Details hierzu finden sich Hinweis 815972.
Zuordnung der Substitution
Abschließend muss die Substitution noch dem Kostenrechnungskreis zugewiesen und aktiviert werden (IMG siehe oben,à …Substitutionsregeln zuordnen), Transaktion 0KEL:
Kostenrechnungskreis
Substitution
Aktivkennzeichen
<XXXX>
<Substitution>
Kennzeichen 0,1,2,3,4 (siehe unten)
Customizing – Aktivierung der Substitution im Kostenrechnungskreis
Aktivkennzeichen
Kennzeichen
Bedeutung
0
Es werden keine Substitutionen verwendet. Das Profit Center wird aus dem Betriebsegment des Artikelstammes abgeleitet.
1
Die Substitution wird bei ‚Cross Company’ und sonstigen Abwicklungen aufgerufen. Bei ‚Cross-Company-Abwicklungen’ erfolgt der Aufruf nur zum Zeitpunkt ‚Faktura anlegen’.
2
Die Substitutionsregel wird nur im Falle einer ‚Cross Company’ Abwicklung verwendet und der Aufruf erfolgt nur zum Zeitpunkt ‚Faktura anlegen’.
3
Die Substitution wird bei ‚Cross Company’ und sonstigen Abwicklungen aufgerufen. Bei ‚Cross-Company-Abwicklungen’ erfolgt der Aufruf zu den Zeitpunkten ‚Kundenauftrag anlegen’ und ‚Faktura anlegen’.
4
Die Substitutionsregel wird nur im Falle einer ‚Cross Company-Abwicklung’ verwendet, der Aufruf erfolgt zu den Zeitpunkten ‚Kundenauftrag anlegen’ und ‚Faktura anlegen’.
Aktivkennzeichen für Substitutionen
Details hierzu finden sich zudem im Hinweis 167912. Programmtechnisch findet der Aufruf im Rahmen des Funktionsbausteins COPCA_SD_PRCTR_GET statt. In ihm wird auch das o.g. Aktivierungskennzeichen abgefragt. Dieser Baustein eignet sich somit als Ausgangspunkt zur Fehleranalyse, wenn die Substitution scheinbar überhaupt nicht durchlaufen wird oder falsche bzw. unverständliche Ergebnisse liefert.
Aufruf der PC-Subst. in eigenen Programmen
Bei Bedarf kann die Profitcenter-Substitution auch in eigenen Programmen gerufen werden. Hierzu sind folgende Schritte nötig:
Versorgung der benötigten Felder der Struktur PCASUB
Details zu den Aufrufzeitpunkten finden sich im Beratungshinweis 392273. Die Substitution wird im IMG unter Controlling> Controlling Allgemein> Kontierungslogik> Substitution definieren bzw. Transaktion OKC9 angelegt bzw. gepflegt.
Kostenrechnungs-kreis
Anw. Zeitpunkt
Substitutionsname
Aktivierungs-
grad
1100
1 Belegzeile
DEMO
1
> Umfeld > Substitution
Pro Substitutionsschritt kann eine Voraussetzung (Bedingung) angegeben und das CO-Kontierungsobjekt auf folgende Weise zurückgegeben werden:
Konstanter Wert
Feld an Feld-Zuweisung (z.B. Kostenstelle = Betrieb)
Exit
Im Rahmen der Substitutionsbearbeitung stehen folgende Datenstrukturen zur Verfügung, wobei nicht alle Strukturen / Felder in jedem Aufrufkontext vollständig gefüllt sind:
Die Rückgabe des jeweiligen Kontierungsobjektes erfolgt im entsprechenden Feld der Struktur COBL.
Validierung im Rahmen der Konsolidierungsvorbereitung
Es sollen folgende Sachverhalte validiert werden:
1. Wenn ein Konto bebucht wird, welches im Set ZFI_KONTEN_BWA_RS(Rückstellungen) enthalten ist, soll geprüft werden, ob a) überhaupt eine Bewegungsart kontiert wurde und b) ob es sich dabei um eine für den Rückstellungsspiegel zulässige Bewegungsart handelt. Diese sind wiederum im Set ZFI_BWA_RS aufgeführt.
Vaidierung zum Zeitpunkt 2 (Belegposition):
Voraussetzung: BSEG-HKONT IN ZFI_KONTEN_BWA_RS
Prüfung: BSEG-BEWAR <> '' AND BSEG-BEWAR IN ZFI_BWA_RS
2. Wenn ein Konto bebucht wird, welches im Set ZFI_KONTEN_PARTNER enthalten ist, soll geprüft werden, ob es dem System möglich war, eine gültige Partnerkontierung (z.B. aus den Gegenpositionen) abzuleiten.
Validierung zum Zeitpunkt 3 (kompletter Beleg): (...muss hier gemacht werden, da die 'Vererbung' der Partnerges. in die Gegenpositionen erst zu diesem Zeitpunkt erfolgt)
Voraussetzung: BKPF-GLVOR <> 'RFBV'
nicht bei Vorerfassung, da die Ableitung der Partnerges. erst im Modus 'Buchen' erfolgt.
Prüfung: Exit U901
Coding-Auszug U901:
Code:
* RA_HKONT aufbauen (Nachlesen aus Set...)
...
*----------------------------------------------------------------------*
* Abfrage Partnerkontierung für alle Belegzeilen, deren
* Konto im SET enthalten ist
* Die Selektionsrange darf aber nicht leer sein, sonst meckert er
* bei jedem Konto
*----------------------------------------------------------------------*
check not ra_hkont[] is initial.
loop at bool_data-bseg into bseg where hkont in ra_hkont.
if bseg-vbund is initial.
b_result = b_false.
endif.
endloop.