SAPManDoo - SAP Resource

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.        "2^nd entry, if necessary

* fill TVARVC-fields according to above example

* …

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!

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:

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.

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.

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.

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.

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:

IMG: Vertrieb > Grundfunktionen > Preisfindung > Steuerung der Preisfindung > Konditionsarten definieren

Die Zugriffsfolge MWST beinhaltet im SAP-Standard folgende Zugriffe:

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:

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:

Beispieleinträge zur Kondition MWST (Steuern Inland)

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.

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.

Der Konditionsart NAVS ist im Auslieferungszustand die Zugriffsfolge 0003 zugeordnet:

IMG: Materialwirtschaft > Einkauf > Konditionen > Preisfindung festlegen > Konditionsarten festlegen

Die Zugriffsfolge 0003 sieht im SAP-Standard folgende Zugriffe vor:

IMG: Materialwirtschaft > Einkauf > Konditionen > Preisfindung festlegen > Zugriffsfolgen festlegen

In aller Regel lassen sich sämtliche steuerfindungsrelevanten Konstellationen mithilfe der Tabelle 86 (s.o.) darstellen. Diese beinhaltet folgende Merkmale:

Steuerrelevante Indikatoren für Bestellung

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.

Die Werte zur Konditionsart NAVS werden in der Anwendung mithilfe der Transaktionen MEK1 bzw. MEK2 hinterlegt.

Beispiel:

Beispieleinträge zur Kondition NAVS

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).

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)

Belegfortschreibung im FI ohne Belegverdichtung

Ü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:

Belegfortschreibung im FI mit Belegverdichtung ü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:

Customizing Belegverdichtung (Transaktion OBCY)

Im SAP-Hinweis 36353 sind häufig verwendete Einstellungen für die oben genannten Referenzvorgänge enthalten:

 Empfohlene Einstellungen zur Belegverdichtung gem. SAP-Hinweis 36353

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

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.

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.

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.