fi

Immer wieder taucht die (berechtigte) Frage auf, wie die Eingangsverarbeitung des elektronischen Kontoauzugs den Verwendungszweck analysiert, die zu suchenden Beleg- und/oder Referenznummern extrahiert und wo die relevanten Stellen im Coding sind. Ich will hier versuchen, auf die wichtigsten Stellen einzugehen und die Arbeitsweise (ggf. mit Beispielen im Coding) zu erläutern.

Als Beispiel nehmen wir den Klassiker "Zahlungseingang" (MT940-GVC 051 bzw. SEPA 166) und gehen davon aus, dass die Buchungsregel hierfür sowohl eine Buchung im Hauptbuch (Buchungsbereich 1) erzeugen als auch im Nebenbuch (Buchungsbereich 2) den debitorischen OP anhand der Referenzinformationen ausziffern soll. Die Suche im Verwendungszweck erfolgt anhand des Interprationsalgotithmus 001 (Standardalgorithmus, Details s. http://help.sap.com/saphelp_erp60_sp/helpdata/de/43/0bd56743de11d1896f0000e8322d00/content.htm )

Das Einlesen und Verbuchen erfolge kombiniert, d.h. wir verwenden die Transaktion FF_5 (Report RFEBKA00).

Zunächst wird der Einlesevorgang in Abhängigkeit des verwendeten Kontoauszugsformats gestartet. Je nach Format werden die entsprechenden Einlese-Reports gerufen, z.B.

Report RFEBKA00, Zl.410 ff.:

*---------------------------------------------------------------*
* Einlesen im richtigen Format *
*---------------------------------------------------------------*
IF einlesen = 'X'.
  CASE format.
    WHEN 'M'.
*   Format: MultiCash (AUSZUG.TXT und UMSAT.TXT)
      PERFORM multicash(rfeka200).
    WHEN 'S'.
*   Format: SWIFT MT940 (mit Strukturiertem Feld 86)
    PERFORM swift_mt940(rfeka400). 
...

Anschließend wird die Verbuchung aufgerufen:

Report RFEBKA00, Formroutine automatic_processing

...

PERFORM einzelposten_auswerten(rfebbu10) USING 'X'.

...

Report RFEBBU10, Formroutine einzelposten_auswerten

Hier werden zunächst die für die aktuelle Auszugsposition anwendbaren Suchmuster ermittelt (FuBa BSPS_PATTERN_SETUP) und angewandt (FuBa BSPS_PATTERN_SEARCH).

Die Standardinterpretation erfolgt mit dem Aufruf der Routine:

...

 PERFORM interpret_n2p TABLES _t_bapiret2. 
...

Report RFEEBU10, Form-Routine interpret_n2p

In Abhängigkeit des Interpretationsalgorithmus wird hier die Routine analyse_verwendungzweck unter Angabe des relevanten Suchfeldes gerufen:

...

CASE febep-intag.
  WHEN '000'.
* do nothing
  WHEN '001'.
* Standardalgo: Führt Suche nach BELNR bzw. XBLNR aus,
* wenn BELNR bzw. XBLNR Range nicht initial ist.
   IF NOT filter IS INITIAL.
     PERFORM analyse_verwendungszweck USING 'BELNR'.
   ENDIF.
   IF NOT tfilter IS INITIAL.
     PERFORM analyse_verwendungszweck USING 'XBLNR'.
   ENDIF.
  WHEN '011'.

...

Im Rahmen dieser CASE-Anweisung erfolgt auch der Aufruf der kundeneigenen Interpretationsalgorithmen:

...

  WHEN OTHERS.
* user algorithm according to naming convention "hw597428
    CONCATENATE 'Z_FIEB_' febep-intag '_ALGORITHM'
    INTO l_funct.

...

CALL FUNCTION l_funct
   EXPORTING
     i_note_to_payee = l_note_to_payee
...

Ein Hinweis zur Simulationsfunktion im Suchmuster-Customizing. Hier wird nur eine Teilmenge der zur Verfügung stehenden Interpretationsalgorithmen unterstützt und kundeneigene Algorithmen gar nicht! Details s. hier: http://fico-forum.de/fico_forum/thread.php?board=2&thread=1500#3

In der Routine ANALYSE_VERWENDUNGSZWECK (RFEBBU10) erfolgt nun in Abhängigkeit des zu suchenden Feldes...

CASE sfnam.

...zunächst die Analyse des Verwendungszwecks (Details s. Kommentare im Coding)

  WHEN 'XBLNR'.
      PERFORM search_xblnr.

Report RFEBBU10, Routine SEARCH_XBLNR:

" in 'puffer' stehen die zusammengesetzten
" Zeilen des Verwendungszwecks als ein
" langer String drin...
...
" hier schmeisst er alle Sonderzeichen raus bzw. ersetzt sie durch Leerzeichen,
" somit wird aus XY123-456 --> XY123 456
" als Sonderzeichen werden betrachtet:. , < > & " % ! ( ) = ? : - # * + / " 
  TRANSLATE puffer USING convert2.

" jetzt wirft er alle mehrfachen Leerzeichen raus
" somit wird aus 'Kalle   ist  doof' --> 'Kalle ist doof'
  CONDENSE puffer.
  puffer2 = puffer.

" jetzt werden alle übrigen Leerzeichen durch ; ersetzt --> XY123;456
  TRANSLATE puffer USING convert3.
  REFRESH treffer.

...
" hier zerlegt er den Verw.zweck anhand ';' in Teilstrings
" und guckt, ob die Teilstrings in dem vom Benutzer angegeben
" Vorgabeintervall für XBLNR liegen (hier: 'XY123' und '456')
" Falls ja - als potenzielle Treffer merken
  PERFORM is_puffer_in_tfilter.

" jetzt die zweite Runde, diesmal gehts den Buchstaben
" an den Kragen, ansonsten analog wie oben
  puffer = puffer2.
  TRANSLATE puffer USING convert1.
...
" jetzt bleibt '123' und '456' über...
...
" doppelte raus (also '456' bleibt nur einmal stehen)
  PERFORM delete_double_treffer.nbsp;# _ ; 

Insbesondere sind Sonderzeichen im Referenzfeld wie '-' oder '/' also ein Problem, weil diese von der Suche ausgeschlossen werden. In diesen Fällen muss schlimmstenfalls eine eigene Referenznummernsuche mithilfe der einschlägigen Erweiterungsmöglichkeiten implementiert werden.

Eine Auflistung aller Erweiterungsmöglichkeiten im Rahmen des elektronischen Kontoauszuges findet sich im Beratungs-Hinweis 494777.

In der int. Tabelle 'treffer' stehen nun alle potenziellen Treffer drin, d.h. alle die Zeichenfolgen, die aus dem Verwendungszweck extrahiert werden konnten und in die Intervallvorgabe, die vom Benutzer beim Einstieg in die FF_5 mitgegeben wurde, passen. Mit diesen potenziellen Treffern wird nun ein 'Probelesen' veranstaltet, d.h. das System versucht mit diesen Referenzen passende Belege von der Datenbank zu lesen.

Report RFEBBU10, Routine ANALYSE_VERWENDUNGSZWECK

...
   PERFORM x-treffer_probelesen.

Report RFEBBU10, Routine x-treffer_probelesen

...
 LOOP AT treffer.
    SELECT * FROM bkpf WHERE bukrs = febko-bukrs
                         AND bstat = ' '
                         AND xblnr = treffer-nummer.   ...

Etwaige Treffer werden dann im Anschluss in die Tabelle FEBCL geschrieben und der Buchungsschnittstelle übergeben.

UPDATE: Mit Hinweis "2092366 - Vorerfassung über BAPI_ACC_DOCUMENT_POST" ist die Vorerfassung nun auch mit dem genannten BAPI im Standard möglich. Allerdings sind die Anpassungen erst in neueren Releases verfügbar und können lt. Hinweis auch nicht vorab eingespielt werden. Falls Ihr Release dies also noch nicht hergibt, können Sie sich wie folgt behelfen...:

Ohne weiteres zutun ist eine Vorerfassung von FI-Belegen mit den einschlägigen BAPIs nicht möglich. Man kann das System jedoch mithilfe des Business Transaction Events (BTE) RWBAPI01 austricksen und damit doch noch zum gewünschten Ergebnis kommen. Im Detail ist folgendes zu tun:

1. BTE RWBAPI01 implementieren wie im Hinweis 487722 im Abschnitt "Implementierung des Business Transaction Event (BTE, auch OPEN FI) RWBAPI01 mit Erweiterungsstruktur EXTENSION1 an BAPI_ACC_DOCUMENT_POST" beschrieben.

2. Damit der BTE durchlaufen wird, muss der BAPI_ACC_DOCUMENT_POST mit der Tabelle EXTENSION1 (wobei hier ein einfacher Dummyeintrag genügt) gerufen werden:

DATA:
  lit_extension1     TYPE TABLE OF bapiacextc,
  ls_extension1      TYPE bapiacextc.
...

ls_extension1-field1 = 'Test'.
append ls_extension1 to lit_extension1.
...

call function 'BAPI_ACC_DOCUMENT_POST'
  exporting
   ...
  importing
    ...
  tables
...
    extension1        = lit_extension1
...

3. Im BTE-Baustein wird dann (natürlich nur für die gewünschten Geschäftsvorfälle, d.h. es ist auf hinreichend scharfe Abgrenzung zum übrigen Belegaufkommen, welches normal gebucht werden soll, zu achten) das Feld STATUS_NEW der Struktur DOCUMENT_HEADER auf '2' (ungeprüft) gesetzt.

Mithilfe des BadIs FEB_BADI kann bei Bedarf umfänglich Einfluss auf die Buchungslogik des elektronischen Kontoauszugs genommen werden. Der BadI wird nach Interpretation vor der Verbuchung gerufen. Dabei werden die von der Standardverarbeitung generierten Buchungssätze in Tabellenform (Struktur FTPOST) bereitgestellt. Der Aufbau der Buchungstabelle ist dabei wie folgt:

Der BadI-Aufruf erfolgt zudem getrennt nach Buchungsbereich (Import-Parameter I_POSTING_AREA, 1 = Bankbuchhaltung, 2 = Nebenbuch).

Das Verfahren soll an folgendem Beispiel erläutert werden:

Im Kontoauszug werden Gutschriften von einem Zahlungskartenprovider gesendet. Der hierbei ausgewiesene Betrag ist bereits um die Transaktionsgebühr reduziert (Zahlung des Kunden über 100,--, gutgeschrieben wird der Betrag abzüglich 3% Provision, also 97,--). Das Unternehmen möchte den Gebührenanteil auf ein separates Gebühren-Konto mit Ausweis der Vorsteuer buchen. In der Standard-Eingangsverarbeitung ist der Geschäftsvorfall entsprechend gecustomized worden, dass im Buchungsbereich 1 (Bankbuchhaltung) folgender Buchungssatz erzeugt wird:

Per         Bank (97,--)     an           Zahlungskartenverrechnungskonto (97,--)

Mithilfe des vorliegenden BadIs soll die Buchung nun so umgestaltet werden, dass folgender Buchungssatz herauskommt:

Per         Bank (97,--)

                Gebühr (2,70)  ->  KST 4711

                VSt (--,30)        an           Zahlungskartenverrechnungskonto (100,--)

Hierzu sind demnach folgende Manipulationen an der Buchungstabelle notwendig:

• Anpassen des Betrages in der Belegposition „Zahlungskartenverrechnungskonto“
• Hinzufügen der Gebührenposition unter Angabe des entsprechenden Steuerkennzeichens und der Kostenstelle
• Aktivieren der Funktion „Steuer rechnen“ im Belegkopf

Dazu wird mithilfe der Transaktion SE19 eine Implementierung des BadIs FEB_BADI angelegt und geeignetes Coding zur Methode CHANGE_POSTING_DATA eingefügt:

METHOD if_ex_feb_badi~change_posting_data.

  DATA: ls_ftpost TYPE ftpost,
        l_string  TYPE string,
        ls_febre  TYPE febre,
        l_fees    TYPE string,
        l_brutto  TYPE p DECIMALS 2,
        l_len     TYPE sy-index,
        l_count   TYPE count_pi.

  CONSTANTS: lc_feeaccount TYPE bseg-hkont VALUE '0000456701',
             lc_taxfees    TYPE bseg-mwskz VALUE 'XY'.
 

  CHECK i_febko-anwnd = '0001'.              "nur Elko
  CHECK NOT t_ftpost[] IS INITIAL.           "Buchungen?

* Auf hinreichend scharfe Abgrenzung des Geschäftsvorfalls achten!!!!   IF i_febko-absnd(8) = 'XYZ-BANK'     AND    "nur XYZ-Bank
     i_febko-bukrs    = 'XYZ'     AND         "nur Bk XYZ
     i_febep-vgint    = '0016'    AND         "nur Zahlungskarten
     i_ikofi-ktos2    = 'ZKVERR'  AND         "Buchung auf ZK-Verr. kto
     i_posting_area   = '1'.                  "nur Buchungsber. 1

**********************************************************************
*
*  Standard-Buchung:
*      Bank            an Zahlungskarten-Verrechnungskonto 100,--
*
*  Buchung NACH folgendem Eingriff in die Buchungslogik
*    (g sei der Gebührenanteil von 100,-)
*
*      Bank     100,--
*      Gebühren g      an ZK-Verrechnungskonto 100,-- + g
*
*    Die Gebühren werden dabei mit Steuer (Kz. XY) gebucht
**********************************************************************

*   Höchsten Positions-Index holen und nächsthöheren ermitteln
    DESCRIBE TABLE t_ftpost.
    READ TABLE t_ftpost INDEX sy-tfill INTO ls_ftpost.
    IF sy-subrc = 0.
      l_count = ls_ftpost-count + 1.
    ENDIF.
    CHECK l_count GT 0.

*   Gebühr aus Verwendungszweck rausklamüsern
    LOOP AT t_febre INTO ls_febre.
      CONCATENATE l_string ls_febre-vwezw INTO l_string.
    ENDLOOP.
*   Gebühren stehen (in diesem Fall) ganz am Ende des Verwendungszwecks
    l_len = strlen( l_string ) - 7.
    l_fees = l_string+l_len(7).
*   Säubern...
    TRANSLATE l_fees USING ',.- / '.
    CONDENSE l_fees NO-GAPS.
*   Bruttobetrag = gutgeschriebener Betrag + Gebühren
    l_brutto = i_febep-kwbtr + l_fees.

*   Buchungstabelle modifizieren

*   1. Betrag der Pos. ZK-Verr. Konto auf brutto anpassen
    LOOP AT t_ftpost INTO ls_ftpost.
      CHECK ls_ftpost-count = '002'
        AND ls_ftpost-fnam  = 'BSEG-WRBTR'.
*     Bruttobetrag auf ZK-Verr.konto buchen
      WRITE l_brutto TO ls_ftpost-fval LEFT-JUSTIFIED.
      MODIFY t_ftpost FROM ls_ftpost.
    ENDLOOP.

*   2. Flag "Steuer rechnen" zum Belegkopf hinzufügen
    ls_ftpost-stype = 'K'.
    ls_ftpost-count = '001'.
    ls_ftpost-fnam = 'BKPF-XMWST'.
    ls_ftpost-fval = 'X'.
    INSERT ls_ftpost INTO t_ftpost INDEX 1.

*   3. Separate Buchungszeile hinzufügen: Gebühr auf Gebührenkonto
    ls_ftpost-stype = 'P'.
    ls_ftpost-count = l_count.

    ls_ftpost-fnam = 'BSEG-BSCHL'.
    ls_ftpost-fval = '40'.
    APPEND ls_ftpost TO t_ftpost.
    ls_ftpost-fnam = 'BSEG-HKONT'.
    ls_ftpost-fval = lc_feeaccount.   "Gebührenkonto
    APPEND ls_ftpost TO t_ftpost.
    ls_ftpost-fnam = 'BSEG-WRBTR'.
    ls_ftpost-fval = l_fees.
    APPEND ls_ftpost TO t_ftpost.
    ls_ftpost-fnam = 'BSEG-ZUONR'.
    ls_ftpost-fval = i_febep-zuonr.
    APPEND ls_ftpost TO t_ftpost.
    ls_ftpost-fnam = 'BSEG-MWSKZ'.
    ls_ftpost-fval = lc_taxfees.      "Steuer-Kz.
    APPEND ls_ftpost TO t_ftpost.
    ls_ftpost-fnam = 'BSEG-SGTXT'.
    ls_ftpost-fval = text-001.        "Buchungstext
    APPEND ls_ftpost TO t_ftpost.
    ls_ftpost-fnam = 'COBL-KOSTL'.
    ls_ftpost-fval = <my_kostl>.      “Kostenstelle
    APPEND ls_ftpost TO t_ftpost.

  ENDIF.

ENDMETHOD.

Aus aktuellem Anlass wurde ich daran erinnert, dass einige Banken in ihren elektronischen Kontoauszügen (MT940-Format) "technische" Valutadaten liefern, da die Banken ja zuweilen so ihren eigenen Kalender verwenden, wo jeder Monat 30 Tage hat. Dabei kommt z.T. so was skurriles zustande wie bspw. der 30. Februar. Der (Bank-) Fachmann lächelt, die Eingangsverarbeitung des elektronischen Kontoauszugs hat hier leider keinen Humor und quittiert dererlei Auszüge mit der Fehlermeldung FB080 - ungültiges Datum...

Schuld daran sind wie gesagt die "technischen" Valuta-Daten, die in den MT940-Dateien (Satzart :61:) vorhanden sind:

Bsp.:

:20:DEUTDEFFXXXX

:25:67070010/….

:28C:00072/001

:60F:C070412EUR0,00

:61:070230C1604,35NCHKNONREF//1804480992

Das Problem betrifft natürlich nur den Februar,  da die übrigen Monate ja mindestens 30 Tage haben.

Entweder man editiert die Dateien manuell vor der Verarbeitung mit einem geeigneten Editor oder löst das Problem mithilfe der SMOD-Erweiterung FEB00004:

Funktionsexit:          EXIT_RFEKA400_001
Include:                  ZXF01U06

Coding:

* Prüfen, ob wieder 30. Februar von der Bank geliefert wurde... Dreckspack!
DATA: check_datum(6) TYPE c.
DATA: ls_raw_data LIKE LINE OF t_raw_data.

LOOP AT t_raw_data INTO ls_raw_data.
  CASE ls_raw_data-line+0(4).
    WHEN ':61:'.
      check_datum = ls_raw_data-line+4(6).
      IF check_datum+2(2) = '02' AND check_datum+4(2) >= '30'.  "FUUUUUUUUUUU.....
        check_datum+4(2) = '28'.    "Schaltjahr? ham wa nich'
      ENDIF.
      ls_raw_data-line+4(6) = check_datum.
      MODIFY t_raw_data FROM ls_raw_data TRANSPORTING line.
  ENDCASE.
ENDLOOP.

Die Einzelpostenanzeigen im FI für kreditorische, debitorische und Sachkonten-Einzelposten (Transaktionen FBLxN bzw. FAGLL03) bieten zahlreiche Auswertungsmöglichkeiten und sind sehr variabel in der Darstellung. Unter anderem steht ein umfänglicher Feldvorrat zur Verfügung, der zur Anzeige gebracht werden kann.  

Hierzu muss man verstehen, dass die Einzelpostentransaktionen auf eigenen, im Zuge der Belegbuchung fortgeschriebenen Tabellen operieren. Diese Tabellen werden zuweilen auch Sekundärindizes genannt. Im einzelnen sind dies:

Die o.g. Einzelpostentabellen enthalten dabei sowohl Angaben aus der Belegposition (Tab. BSEG) als auch aus dem Belegkopf (BKPF). Somit lässt sich festhalten, dass die Einzelpostentabellen eine Teilmenge der abgemischten Informationen aus Belegposition und –kopf darstellen. Die Felder der Einzelpostentabellen werden im Rahmen der Verbuchung fortgeschrieben und können ohne weiteres Zutun in den einschlägigen Transaktionen verwendet werden.

Wie oben ausgeführt, enthalten die Einzelpostentabellen nur eine Teilmenge der Informationen, die im eigentlichen Buchhaltungsbeleg zur Verfügung stehen. Über die Funktion Sonderfelder kann das System angewiesen werden, bestimmte Felder zur Laufzeit aus dem Buchhaltungsbeleg nachzulesen.  

Ein Beispiel hierfür ist das Feld „Einkaufsbeleg“ (EBELN). Perfide dabei ist, dass es im Default-Feldvorrat der Einzelpostenlisten sogar schon enthalten ist, aber nicht befüllt wird, da es bspw. in der Tabelle BSIS gar nicht enthalten ist. D.h., das System müsste zum Einzelposten die entsprechende Position des Buchhaltungsbeleges (Tab. BSEG) nachlesen, um das Feld EBELN mit Werten zu versorgen. Genau das passiert, wenn diese Felder als Sonderfelder im Customizing deklariert werden:

Customizing-Leitfaden: Finanzwesen (neu) - Hauptbuchhaltung (neu) – Stammdaten – Sachkonten -  Einzelposten - Sonderfelder für Einzelpostenanzeige definieren

Anschließend stehen die hier aufgenommen Felder in der Einzelpostenanzeige (mit Werten versorgt) im Feldvorrat zur Verfügung.

Hinweis: da hier pro Einzelposten ein zusätzlicher Datenbank-SELECT auf die in der Spalte „Tabelle“ angegebene Datenbanktabelle stattfindet, hat dies u.U. natürlich gewisse Auswirkungen auf Performance.

Über das oben beschriebene hinaus, kann es erforderlich bzw. gewünscht sein, zusätzliche Informationen in den Einzelpostenlisten zur Anzeige zu bringen bzw. den Feldvorrat um eigene Felder zu ergänzen. Auch hier stehen modifikationsfreie (!) Möglichkeiten zur Verfügung, die allerdings gewisse Kenntnisse in der ABAP-Programmierung erfordern.  

Zunächst müssen die neuen Felder dem Feldvorrat hinzugefügt werden. Dazu wird ein Append an die Strukturen RFPOS/RFPOSX (Transaktionen FBLxN) bzw. FAGLPOSE (Transaktion FAGLL03) gehängt, welches die neuen Felder enthält. Den nachfolgenden Abschnitten lässt sich entnehmen, wie die so hinzugefügten Felder mit Werten versorgt werden können.

Erweiterung über Business Transaction Event (nur Transaktionen FBLxN)  

Business Transaction Events (kurz BTE, vormals auch OPEN-FI betitelt) gehören zu einer Erweiterungstechnologie der SAP (ähnlich  den User-Exits), die es ermöglicht, kundeneigenes Coding in Form von Funktionsbausteinen an vordefinierte Andockpunkte zu koppeln. Für die Befüllung eigener Felder der Einzelpostenliste steht der BTE 00001650 (P&S-Schnittstelle) bereit. Ein (zugegebenermaßen einfaches aber anschauliches) Beispiel inkl. Muster-Coding findet sich im SAP-Hinweis 569939.

Mit dem genannten BadI können die neuen Felder mit Werten versorgt werden. Ein (zugegebenermaßen einfaches aber anschauliches) Beispiel inkl. Muster-Coding findet sich im SAP-Hinweis 1174945. Zudem befindet sich nachfolgend in Anlehnung an das Vorgehen im genannten Hinweis ein bebildertes Beispiel zum Hinzufügen der Kostenstellenbezeichnung.

Beispiel mit BadI:

Für die Sachkonteneinzelpostenliste FAGLL03 soll zusätzlich zur Kostenstelle auch die Kostenstellenbezeichnung (Kurztext) in den Feldvorrat aufgenommen werden.

Hierfür fügen wir zunächst einen geeigneten Append der Einzelpostenstruktur FAGLPOSE hinzu. In diesem wird das neue Feld ZZ_KTEXT eingefügt.

Da nicht auszuschließen ist, dass die Struktur von SAP in kommenden Releases um zusätzliche Felder erweitert wird, empfiehlt es sich, den Feldnamen im Kundennamensraum zu wählen. Sofern sinnvoll, kann hierfür auch noch ein eigenes Datenelement angelegt werden. Da wir uns hier auf einen Standard-Datentyp (zu Feld CSKT-KTEXT) beziehen können, ist dies im vorliegenden Fall nicht notwendig.

Annschließend legen wir mithilfe der Transaktion SE19 eine Implementierung des BadIs FAGL_ITEMS_CH_DATA an, in der das neue Feld versorgt wird. Dazu wird zur Methode CHANGE_ITEMS geeignetes Coding hinterlegt:

METHOD if_ex_fagl_items_ch_data~change_items.

  DATA: wa_items TYPE faglposx.

  LOOP AT ct_items INTO wa_items.
*   Nachlesen Kurztext aus K'Stellenstammsatz
    CLEAR wa_items-zz_ktext.
    IF NOT wa_items-kostl IS INITIAL AND
       NOT wa_items-kokrs IS INITIAL.
      SELECT ktext FROM  cskt INTO wa_items-zz_ktext
             UP TO 1 ROWS
             WHERE  spras  = sy-langu
             AND    kokrs  = wa_items-kokrs
             AND    kostl  = wa_items-kostl
             AND    datbi GE sy-datum.
      ENDSELECT.
      MODIFY ct_items FROM wa_items.
    ENDIF.
  ENDLOOP.

ENDMETHOD.  

Abschließend wird die BadI-Implementierung aktiviert. Wie u.a. im Hinweis 1174945 erwähnt, sollte vor der Verwendung des neuen Feldes der Report BALVBUFDEL ausgeführt werden, um den ALV-Puffer zu initialisieren.  

Im Ergebnis steht nun das neue Feld im Feldvorrat zur Verfügung und kann bei Bedarf der Anzeige hinzugefügt werden.

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!

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.

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)

413956 - Validierung kompletter Beleg (Zeitpunkt 3)

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 GET_EXIT_TITLES

Block einfügen

 exits-name = 'U900'.  "Kd.namensraum: U9xx / Zxxx / Yxxx
 exits-param = c_exit_param_class. "s. HW 48121 
 exits-title = ''. "<---insert appropriate text here
 append exits.
 

Block einfügen

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

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)

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 interne Verrechnung ermittelt wird. Details hierzu finden sich Hinweis 815972.

Abschließend muss die Substitution noch dem Kostenrechnungskreis zugewiesen und aktiviert werden (IMG siehe oben, à …Substitutionsregeln zuordnen), Transaktion 0KEL:

Customizing – Aktivierung der Substitution im Kostenrechnungskreis

Aktivkennzeichen

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
• Aufruf des Funktionsbausteins COPCA_SD_PRCTR_GET

Beispiel:

report zmyprog.
* PC-Substitution explizit in eigenem Coding ausführen
data:  ls_pcasub type pcasub,          "Workarea f. PC-Substitution
       l_prctr   type prctr.           „Substituiertes PC

* WorkArea PCASUB (Subst.-Schnittstelle) füllen
ls_pcasub-werks = ‚1234‘.
ls_pcasub-… = …
* Substitution aufrufen
  call function 'COPCA_SD_PRCTR_GET'
    exporting
      i_pcasub = ls_pcasub
      i_bukrs  = ‚1000‘
    importing
      prctr    = l_prctr
    exceptions
      no_bukrs = 1
      others   = 2.
* Fehlerbehandlung …

CO-Substitution

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.

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