Automatisierte Anlage von Abrechnungsvorschriften zu Innenaufträgen
Um eine Abrechnungsvorschrift zu einem Innenauftrag automatisiert anzulegen, sollte in neueren Releases die Standardfunktionalität "automatische Generierung von Abrechnungsvorschriften" verwendet werden. Hierüber steht ein umfassendes Framework zur Verfügung, mit dem die meisten Use-Cases abgedeckt sein sollten. Details hierzu finden sich im Customizing-Leitfaden unter Controlling - Innenaufträge - Istbuchungen - Abrechnung - Automatische Generierung von Abrechnungsvorschriften ...
Für Datenübernahmen von Innenaufträgen, d.h. Übernahme der Stammdaten inkl. Abrechnungsvorschrift kann der BAPI BAPI_INTERNALORDER_CREATE verwendet werden.
Sollte es in Ausnahmefällen jedoch nötig sein, per Programm Abrechnungsvorschriften zu bestehenden Innenauftragen zu generieren, steht der Funktionsbaustein: K_ORDER_SRULE_ADD zur Verfügung, der allerdings einen großen Nachteil hat: er wurde von SAP in neueren Releases deaktiviert, d.h. im Coding ist ein sofortiger Rücksprung zur rufenden Anwendung implementiert, der jegliche Ausführung unterbindet:
************************************************************
************************************************************
RETURN. "fm will be deleted within the next releases ...
************************************************************
************************************************************
D.h., um ihn zu verwenden, muss entweder der oben stehende Befehl per Modifikation ausgebaut oder eine Kopie des Funktionsbausteins im Kundennamensraum angelegt werden.
Schade eigentlich, denn der Funktionsbaustein werkelt gut.
Der FuBa kann wie folgt gerufen werden:
*&---------------------------------------------------------------------*
*& Report YDEMO_ORDER_SRULE_ADD
*&
*&---------------------------------------------------------------------*
*& maschinelles Anlegen einer Abrechnungsvorschrift zu CO-Innenaufträgen
*&---------------------------------------------------------------------*
REPORT ydemo_order_srule_add.
* Schnittstelle f. BAPI
DATA: l_objnr LIKE aufk-objnr. "Objektnummer
DATA:
* Tabelle mit Abrechnungsvorschriften
lt_srules TYPE TABLE OF srules_ext,
* Tabelle f. Übergabe CO-PA Felder bei Abrechnung ins Ergebnis
* Angabe der Tabelle ist Pflicht, auch wenn nicht ins CO-PA
* abgerechnet werden soll...
lt_criteria TYPE TABLE OF bapi_copa_data,
l_rule_inserted LIKE sy-batch.
DATA: ls_srule TYPE srules_ext.
* Objektnummer zusammenbauen oder für einen gegebenen Innenauftrag
* einfach aus der Tab. AUFK nachlesen (Feld AUFK-OBJNR)
* Zusammenbauen ist aber auch recht einfach:
* Format Objektnummer f. CO-Aufträge: XX999999999999
* XX = Objektart OR
* 999999999999 = 12-stellige Innenauftragsnummer
l_objnr(2) = 'OR'.
l_objnr+2(12) = '000000400000'.
* Abrechnungsvorschrift zusammenbasteln...
* Abrechnungsart (engl. Festwerte)
* z.B. FUL = Gesamtabrechnung
* PER = periodische Abrechnung
ls_srule-settl_type = 'PER'.
* ls_srule-SOURCE "opt: Ursprungszuordnung
* Aufteilung
ls_srule-percentage = 100. "prozentuale Aufteilung ODER
*ls_srule-equiv_number "Äquivalenzziffer ODER
*ls_srule-amount "Betrag f. Betragsabrechnung
* Das Abrechungsempfängerobjekt ergibt sich aus der selektiven
* Befüllung der folgenden Felder:
*ls_srule-bus_area "Geschäftsbereich
*ls_srule-comp_code "Buchungskreis
*ls_srule-gl_account "Sachkonto
*ls_srule-profit_ctr "Profitcenter
ls_srule-costcenter = '0000002001'. "Kostenstelle
*ls_srule-orderid "Innenaauftrag
*ls_srule-wbs_element "PSP-Element
*ls_srule-asset_no "Anlage
* ...
APPEND ls_srule TO lt_srules.
CALL FUNCTION 'K_ORDER_SRULE_ADD'
EXPORTING
object_no = l_objnr
IMPORTING
flg_rule_inserted = l_rule_inserted
TABLES
srules = lt_srules
criteria = lt_criteria
EXCEPTIONS
wrong_input = 1
error_occurred = 2
object_not_found = 3
activity_not_allowed = 4
OTHERS = 5.
IF sy-subrc <> 0.
WRITE: / 'Fehler', sy-subrc, 'beim Anlegen der Abrechnungsvorschrift'.
ELSE.
IF l_rule_inserted = 'X'.
WRITE: 'Abrechnungsvorschrift hinzugefügt'.
COMMIT WORK.
ELSE.
WRITE: 'Abrechnungsvorschrift nicht hinzugefügt'.
ENDIF.
ENDIF.
Fremddatenübernahme ins CO-PA
Im nachfolgenden Link ist eine ausführliche Anleitung enthalten, wie Fremddaten ohne Entwicklungsaufwand ins CO-PA geladen werden können:
https://drive.google.com/file/d/0B1_CTm8mzZEQTkowLXRwSDRhYVU/edit?usp=sharing
Viel Erfolg!
Ausgabe von Mahnungen und Zahlungsavisen per EMail o. Fax
Nachfogend eine Anleitung, wie Zahlungsavise und/oder Mahnungen per eMail oder Fax aus SAP heraus versendet werden können...
https://drive.google.com/file/d/0B1_CTm8mzZEQMml1Uk5xYjZkSHM/edit?usp=sharing
Als Absender wird dabei ohne weiteres Zutun die Adresse des zugeordneten Sachbearbeiters verwendet. Dies kann jedoch übersteuert werden, Details hierzu s. SAP-Hinweis 988859 - Variable Absenderangabe beim Versenden von E-Mails und dessen verwandte Hinweise!
Neuerdings ist es übrigens auch möglich, die erzeugten Mahn-Mails mit CC und BCC-Empfängern zu versehen (z.B. um die Mahnungen an den zuständigen KeyAccount-Manager z. Kenntnis zu versenden). Details hierzu s. Hinweis 2023318.
Viel Erfolg!
Variablen in Selektionsvarianten
Verwendung von Variablen in Selektionsvarianten:
Die dynamische Datumsberechnung ist für alle Selektionsparameter möglich, die vom Typ DATUM (Typ DATS) oder Zeit (TIMS) sind.
Selektionsvariable D

Name der Variablen --> passenden Eintrag auswählen

Beispiel: Tagesdatum – 2 Arbeitstage

-->
Die Definition eigener Variablen ist leider ohne Modifikation nicht möglich. Die Liste der zur Verfügung stehenden dynamischen Datumsvariablen wird im Funktionsbaustein RS_VARI_V_INIT aufgebaut. Hierbei werden Bezeichnung, Typ und Berechnungsfunktionsbaustein pro Variable im System bekannt gemacht. Ggf. könnte man über eine geeignete Erweiterungsimplementierung des o.g. Funktionsbausteins die Liste der Variablen erweitern. Dazu müsste dann noch ein eigener Berechnungsbaustein (z.B. als Kopie des FB RS_VARI_V_1_NEXT_MONTH) ausprogrammiert werden. Sofern zur Berechnung weitere Daten eingegeben werden müssen (z.B. Fabrikkalender), ist darüber hinaus der SAP-Funktionsbaustein RS_VARI_V_SAVE umfänglich anzupassen.
Vor diesem Hintergrund ist von der Verwendung kundeneigener dynamischer Datumsvariablen eher abzuraten.
Für andere Datentypen mit variablem Inhalt kann in der Tabelle TVARV eine Variable angelegt und in Varianten verwendet werden:
SM31 – TVARV – pflegen oder Transaktion STVARV

Auf diese Weise definierte Variablen können nun in Varianten verwendet werden. Der Datentyp des Selektionsparameters muss natürlich mit dem angegebenen Variableninhalt kompatibel sein.

Der Variableninhalt kann entweder manuell im Dialog über die Tabelle TVARV gepflegt oder programmtechnisch gesetzt werden.
Die o.g. Bsp. genannte Variable ZFIC_COPA_PREV_PERIOD wird automatisch auf den „richtigen“ Wert (d.h. im Feb 2012 auf 001.2012) durch ein entsprechendes kundeneigenes Programm gesetzt (Beispielcoding s.u.).
D.h. sofern dafür Sorge getragen wird, dass der Report immer am 1. des Monats VOR allen anderen Reports, die entsprechende Variablen verwenden, läuft, kann die Variable ohne Probleme verwendet werden und ist in Bezug zum aktuellen Datum korrekt gefüllt.
Beispielcoding:
REPORT Y_TVARVC_UPDATE.
TABLES: TVARVC .
DATA: DATUM LIKE SY-DATUM.
DATA: NDAYS TYPE i.
* To be on the safe side, En-/Dequeues
* should be performed on table TVARVC
*...
* Example for Parameter-Variable
TVARVC-TYPE = 'P'.
TVARVC-NUMB = 0. "no multiple entries for PARAMETERS
TVARVC-NAME = 'Y_DAYS_TO_XMAS_EVE'.
DATUM = SY_DATUM.
DATUM+4(4) = '1224'.
IF SY-DATUM > DATUM. "X-mas eve is over – cu next year
DATUM(4) = DATUM(4) + 1.
ENDIF.
NDAYS = DATUM – SY-DATUM.
TVARVC-LOW = NDAYS.
UPDATE TVARVC.
* Example for Select-Option-Variable
TVARVC-TYPE = 'S'.
TVARVC-NAME = 'Y_SO_AGES_FOR_MONOPOLY'.
TVARVC-NUMB = 1. "first entry
TVARVC-SIGN = 'I'. "(I)nclude, (E)xclude
TVARVC-OPTI = 'BT'. "BT = BETWEEN, …
TVARVC-LOW = 8. "Family-fun from age x…
TVARVC-HIGH = 99. "…to y
UPDATE TVARVC.
ADD 1 TO TVARVC-NUMB. "2nd entry, if necessary
* fill TVARVC-fields according to above example
* …
Fakturaschnittstelle ins FI / FI-Beleg unterbinden, CO-PA bleibt
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!
Erweiterung von Report Painter / -Writer Berichten
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.:
- CCSS - Gemeinkostencontrolling
- GLPCT - Profitcenter-Rechnung
- RWCOOM - Berichtstabelle Gemeinkostencontrolling (Spez. Auswertungen)
- V_GLFLEXT - Flexibles Hauptbuch
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.
BAPI-Aufruf BAPI_GOODSMVT_CREATE
Das nachfolgende Coding stellt einen Beispielaufruf für das o.g. BAPI dar:
REPORT ytestbapi.
* test / sample report for BAPI_GOODSMVT_CREATE
* S.ROHDE WNRC 12/2011
PARAMETERS: pa_test AS CHECKBOX DEFAULT 'X'.
DATA: gs_goodsmvt_header TYPE bapi2017_gm_head_01.
DATA: git_return TYPE TABLE OF bapiret2.
DATA: git_items TYPE TABLE OF bapi2017_gm_item_create.
DATA: gs_item LIKE LINE OF git_items.
DATA: g_materialdocument TYPE bapi2017_gm_head_ret-mat_doc.
DATA: g_matdocumentyear TYPE bapi2017_gm_head_ret-doc_year.
DATA: g_goodsmvt_code TYPE bapi2017_gm_code VALUE '06'. "MB11
* All supported transactions can be found in table T158G
* header
CLEAR: gs_goodsmvt_header.
gs_goodsmvt_header-pstng_date = sy-datum. "Posting date
gs_goodsmvt_header-doc_date = sy-datum. "Document date
gs_goodsmvt_header-ref_doc_no = '4711'. "Reference No
gs_goodsmvt_header-pr_uname = sy-uname. "User name
gs_goodsmvt_header-header_txt = 'Test BAPI'. "Header text
* item(s)
CLEAR git_items[].
CLEAR gs_item.
* caution: give article/mat. no. with leading zeroes!!!
gs_item-material = '000000000000002002'. "Art./Mat.No
gs_item-plant = 'C302'. "plant/site
gs_item-stge_loc = '0001'. "Storage loc.
gs_item-move_type = 'Z01'. "Movement type (BwA)
gs_item-entry_qnt = 5. "Quantity
gs_item-entry_uom = 'ST'. "Unit
APPEND gs_item TO git_items.
* call bapi
CALL FUNCTION 'BAPI_GOODSMVT_CREATE'
EXPORTING
goodsmvt_header = gs_goodsmvt_header
goodsmvt_code = g_goodsmvt_code
testrun = pa_test
IMPORTING
materialdocument = g_materialdocument
matdocumentyear = g_matdocumentyear
TABLES
goodsmvt_item = git_items
return = git_return.
* commit work.
IF pa_test IS INITIAL.
COMMIT WORK.
WRITE: / 'Document posted:',
g_materialdocument,
'/',
g_matdocumentyear,
' Returncode:',
sy-subrc.
ENDIF.
* display messages from bapi, if necessary
IF NOT git_return[] IS INITIAL.
CALL FUNCTION 'C14ALD_BAPIRET2_SHOW'
TABLES
i_bapiret2_tab = git_return.
ELSE.
MESSAGE s600(fr) WITH 'no messages occured'
'while BAPI processed'.
ENDIF.
CO-PA Berichte zwischen Ergebnisbereichen kopieren
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 TYPE TABLE OF tkeb1 WITH HEADER LINE.
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 AS CHECKBOX DEFAULT '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 INTO TABLE i_tkeb1
WHERE applclass = 'KE'
AND subclass = '01'
AND tabname LIKE l_tabname_wild
AND repid IN so_repid.
LOOP AT i_tkeb1.
WRITE: / i_tkeb1-applclass,
i_tkeb1-subclass,
i_tkeb1-tabname,
i_tkeb1-repid,
i_tkeb1-form.
l_tabname = i_tkeb1-tabname.
* Zieltabellenname setzen
CALL FUNCTION 'RKE_COPY_CHANGE_TABNAME'
EXPORTING
i_tabname = l_tabname
i_source_erkrs = pa_serkr
i_target_erkrs = pa_terkr
IMPORTING
e_tabname = l_tabname
EXCEPTIONS
no_erkrs_in_tabname = 1
OTHERS = 2.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
* Im Echtlauf Kopierfunktion starten
IF pa_test IS INITIAL.
* Ggf. zuerst Formular kopieren
IF NOT i_tkeb1-form IS INITIAL.
CALL FUNCTION 'RKD_FORM_COPY'
EXPORTING
i_applclass = 'KE'
i_subclass = '01'
i_tabname = i_tkeb1-tabname
i_form = i_tkeb1-form
* I_AKTMDT = 'X'
i_tabname_new = l_tabname
* EXCEPTIONS
* FORM_EXISTS_ALREADY = 1
* FORM_IMPORT_IMPOSSIBLE = 2
* FORM_NOT_FOUND = 3
* OTHERS = 4
.
IF sy-subrc <> 0.
EXIT.
ENDIF.
ENDIF.
* Bericht kopieren
CALL FUNCTION 'RKE_REPORT_COPY'
EXPORTING
repid = i_tkeb1-repid
erkrs = pa_serkr
applclass = i_tkeb1-applclass
subclass = i_tkeb1-subclass
tabname = i_tkeb1-tabname
dest_tabname = l_tabname
EXCEPTIONS
report_not_found = 1
unknown_error = 2
list_elements_not_copied = 3
old_report_version = 4.
CASE sy-subrc.
WHEN 0 OR 3.
MESSAGE i126(ke0c) WITH i_tkeb1-repid i_tkeb1-tabname.
* Bericht &1 (Tabelle &2) wurde kopiert
PERFORM write_msg_prot(sapmkecp) USING
'KE0C' 'I' '126'
i_tkeb1-repid i_tkeb1-tabname
space space.
WHEN 2.
PERFORM write_msg_prot(sapmkecp) USING
'KE/NC' 'E' '000'
i_tkeb1-repid 'SY-SUBRC' sy-subrc
space.
WHEN 4.
IF 0 = 1.
MESSAGE w129(ke0c) WITH i_tkeb1-repid i_tkeb1-tabname.
ENDIF.
* Bericht &1 (Tabelle &2) muss umgesetzt werden
PERFORM write_msg_prot(sapmkecp) USING
'KE0C' 'W' '129'
i_tkeb1-repid i_tkeb1-tabname
space space.
ENDCASE.
ENDIF.
ENDLOOP.
BAPI-Meldungen ausgeben
Nachfolgend einige Hinweise, wie man elegant Return-Nachrichten von BAPIs ausgeben kann.
Neuere BAPIs geben Ihre Meldungen in der Struktur BAPIRET2 zurück.
Bsp.:
DATA:
* Meldungen des BAPI's
git_return TYPE TABLE OF bapiret2.
*-----------------------------------------------------------------------
* BAPI-Call
*-----------------------------------------------------------------------
CALL FUNCTION 'BAPI_ACC_DOCUMENT_POST'
EXPORTING
documentheader = gs_documentheader
IMPORTING
obj_type = g_obj_type
obj_key = g_obj_key
obj_sys = g_obj_sys
TABLES
accountgl = git_accountgl
accountreceivable = git_accountreceivable
currencyamount = git_currencyamount
return = git_return.
Ausgabe:
CALL FUNCTION 'C14ALD_BAPIRET2_SHOW'
TABLES
i_bapiret2_tab = git_return.
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 TYPE TABLE OF bapireturn,
lt_bapiret2 type table of bapiret2.
CALL FUNCTION 'BAPI_...'
EXPORTING
...
TABLES
return = lt_return
...
Konvertieren:
CALL FUNCTION 'EHSWA_490_BAPIRET_CONVERSION'
TABLES
I_BAPIRETURN_MSG_TAB = lt_return
E_BAPIRET2_MSG_TAB = lt_bapiret2.
Ausgabe:
CALL FUNCTION 'C14ALD_BAPIRET2_SHOW'
TABLES
i_bapiret2_tab = lt_bapiret2.
Steuerfindung in Vertriebsbelegen (SD)
In den Standardkalkulationsschemata des Vertriebes wird als Konditionsart zum Ausweis der Ausgangssteuer MWST verwendet (Ausnahme POS-Fakturen, s. weiter unten).
Der Konditionsart MWST ist im SAP-Auslieferungszustand die gleichnamige Zugriffsfolge zugeordnet:
Konditionsart MWST Ausgangssteuer Zugriffsfolge MWST Mehrwertsteuer
Kond.Klasse D Steuern Vorzeichen positiv un
Rechenregel A Prozentual
Konditionstyp D Steuer
Rundungsregel Kaufmännisch
Strukturkond.
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.
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).
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.
/image%2F1473637%2F20170207%2Fob_adae32_profilbild.png)