Overblog Folge diesem Blog
Administration Create my blog
SAPManDoo - SAP Resource

Posts mit #fi tag

Mahnliste RFMAHN21 erweitern

26. August 2017 , Geschrieben von sapmandoo Veröffentlicht in #FI

Im Hinweis 590421 ist eine Möglichkeit beschrieben, die Mahnliste RFMAHN21 um eigene Felder zu erweitern. Bei der im Hinweis genannten Lösung handelt es sich jedoch um eine Modifikation, die vermutlich nicht in jedem System verbaut werden kann/soll. Alternativ lässt sich das Ganze auch mit einem impliziten Enhancement bewerkstelligen, was dann im technischen Sinne eben keine Modifikation mehr darstellt...

Hierzu wird einfach an das Ende der Routine APPEND_MHND_EXT2 im RFMAHN21 ein implizites Enhancement eingefügt, welches dann den Beispielcode aus dem o.g. Hinweis beherbergt (in leicht abgewandelter Form). 

Siehe auch hier

Weiterlesen

IDoc ACC_DOCUMENT - Beispiele

20. Februar 2017 , Geschrieben von sapmandoo Veröffentlicht in #FI, #Basis-Entwicklung allg.

Will man FI-Belege aus externen Quellen ins System buchen, bietet sich die Verwendung von IDocs des Typs ACC_DOCUMENT an. In den nachfolgenden Abschnitten wird die ordnungsgemäße Befüllung des IDoc-Inhalts beschrieben. 

Eigenschaften der IDocs des Typ ACC_DOCUMENT

Nachrichtentyp: ACC_DOCUMENT

Basistyp: ACC_DOCUMENT04

 

Struktur

Die relevanten Segmente des IDocs sind:

 

  • E1BPACHE09 : Kopfzeile

Status : Optional , min. Anzahl : 1 , max. Anzahl : 1

  • E1BPACGL09 : Sachkontenzeile

Status : Optional , min. Anzahl : 1 , max. Anzahl : 999999999

  • E1BPACAR09 : Debitorzeile

Status : Optional , min. Anzahl : 1 , max. Anzahl : 999999999

  • E1BPACAP09 : Kreditorzeile

Status : Optional , min. Anzahl : 1 , max. Anzahl : 999999999

  • E1BPACTX09 : Steuerzeile

Status : Optional , min. Anzahl : 1 , max. Anzahl : 999999999

  • E1BPACCR09 : Währungspositionen

Status : Optional , min. Anzahl : 1 , max. Anzahl : 999999999

 

Der generelle Aufbau ist wie folgt: Ein valides IDoc besteht aus genau einem Kopfsegment E1BPACHE09 und mindestens 2 Positionen. Die Positionen setzen sich jeweils aus einem Segment der Typen E1BPACGL09, E1BPACAP09 oder E1BPACAR09 mit jeweils einem korrespondierenden Betragssegment E1BPACCR09 zusammen. Die Verknüpfung zwischen den Belegpositionen und den Betragssegmenten erfolgt über das Feld ITEMNO_ACC (Positionsnummer).

Minimal-Beleg:

Belegkopf E1BPACHE09

Position 000001

Sachkontenzeile E1BPACGL09 oder

Kreditorenzeile E1BPACAP09 oder

Debitorenzeile E1BPACAR09

Position 000002

Sachkontenzeile E1BPACGL09 oder

Kreditorenzeile E1BPACAP09 oder

Debitorenzeile E1BPACAR09

Position 000001 Betragssegment E1BPACCR09

Position 000002 Betragssegment E1BPACCR09

 

Die Positionsnummern können im Prinzip beliebig vergeben werden, es empfiehlt sich jedoch, eine aufsteigende nummerische Positionsnummernvergabe vorzusehen.

 

Befüllung

Der oben beschriebene Minimalbeleg benötigt mindestens folgende Feldversorgungen:

E1BPACHE09

BUS_ACT             RFBU (Vorgang fix)

USERNAME        USERXYZ

HEADER_TXT      KOPFTEXT (Belegkopftext, optional, sofern Belegart keine Eingabe erfordert)

COMP_CODE     1000 (Buchungskreis)

DOC_DATE         20150227 (Belegdatum)

PSTNG_DATE     20150227 (Buchungsdatum)

DOC_TYPE          SA (Belegart)

REF_DOC_NO    REFERENZ-NR (Referenznummer, optional, sofern Belegart keine Eingabe erfordert)

 

E1BPACGL09  (1. Position, Sachkontenposition)

ITEMNO_ACC    000010  (Positionsnummer)

GL_ACCOUNT    0000160000 (Sachkonto)

ITEM_TEXT         BUCHUNGSTEXT (optional)

ALLOC_NMBR   ZUORDNUNG (optional, ansonsten wird Zuordnung systemseitig gemäß Einstellung im Sachkontenstamm befüllt)

 

E1BPACGL09  (2. Position, Sachkontenposition)

ITEMNO_ACC    000020  (Positionsnummer)

GL_ACCOUNT    0000151000 (Sachkonto)

ITEM_TEXT         BUCHUNGSTEXT (optional)

ALLOC_NMBR   ZUORDNUNG (optional, ansonsten wird Zuordnung systemseitig gemäß Einstellung im Sachkontenstamm befüllt)

 

E1BPACCR09 (zu Position 1)

ITEMNO_ACC    000010

CURRENCY         EUR (Belegwährung)

AMT_DOCCUR  10.00  (Betrag in Belegwährung)

 

E1BPACCR09 (zu Position 2)

ITEMNO_ACC    000020

CURRENCY         EUR

 AMT_DOCCUR   10.00-   

(Achtung: Soll und Haben wird durch positiven bzw. negatives Vorzeichen                          unterschieden, - = Haben, + = Soll)

IDoc-Befüllung WE19

IDoc-Befüllung WE19

Erzeugter Beleg

Erzeugter Beleg

Besonderheit bei Buchung mit Umsatzsteuer

Im Gegensatz zum Batch-Input-Verfahren ist es mit dem Nachrichtentyp ACC_DOCUMENT (bzw. im Endeffekt mit dem dahinterliegenden BAPI_ACC_DOCUMENT_POST) nicht möglich, den Steueranteil einer Buchung vom System generieren zu lassen. D.h., die Steuerinformationen müssen dem IDoc auf folgende Weise mitgegeben werden:

Bei der Position, die die Steuer beinhaltet (i.d.R. die Sachkontenposition) wird der Betrag netto mitgegeben. Zusätzlich wird eine Steuerzeile des Segmenttyps E1BPACTX09 nebst Betragssegment (E1BPACCR09) mit folgenden Informationen benötigt:

 

E1BPACTX09

ITEMNO_ACC 000030

TAX_CODE V1 (Steuerkennzeichen)

 

E1BPACCR09

ITEMNO_ACC 000030

CURRENCY EUR

AMT_DOCCUR 1.60 (Steuerbetrag)

AMT_BASE 8.40 (Steuerbasis)

 

 

Beispiel:

Kreditorische Buchung

per Stromkosten 632500 8,40,-- an Kreditor 100003 10,--

Vorsteuer (V1) 1,60,--

 

 

Belegkopf E1BPACHE09:

BUS_ACT: RFBU

USERNAME: USERXYZ

HEADER_TXT: KOPFTEXT

COMP_CODE: 1000

DOC_DATE: 20150227

PSTNG_DATE: 20150227

DOC_TYPE: KR

REF_DOC_NO: 378455676

 

Kreditorenposition E1BPACAP09:

ITEMNO_ACC 000010

VENDOR_NO 0000100003 (Kreditorennummer)

 

Betragsposition zur Kreditorenposition E1BPACCR09

ITEMNO_ACC 000010

CURRENCY EUR

AMT_DOCCUR 10-

 

Sachkontenposition E1BPACGL09

ITEMNO_ACC 000020

GL_ACCOUNT 0000632500

ITEM_TEXT TESTBUCHUNG MIT STEUER

TAX_CODE V1 (Steuerkennzeichen!)

COSTCENTER 0000001000 (Kostenstelle, Konto 632500 ist Kostenart!)

 

Betragsposition zur Sachkontenposition E1BPACCR09

ITEMNO_ACC 000020

CURRENCY EUR

AMT_DOCCUR 8.40 (netto!)

 

Steuerzeile E1BPACTX09

ITEMNO_ACC 000030

TAX_CODE V1

 

Betragsposition zur Steuerzeile E1BPACCR09

ITEMNO_ACC 000030

CURRENCY EUR

AMT_DOCCUR 1.60 (Steuerbetrag)

AMT_BASE 8.40 (Steuerbasis)

IDoc-Befüllung (WE19)

IDoc-Befüllung (WE19)

Erzeugter Beleg inkl. Steuer

Erzeugter Beleg inkl. Steuer

Weiterlesen

Gegenkonto - das unbekannte Wesen...

19. Januar 2017 , Geschrieben von sapmandoo Veröffentlicht in #FI

Relevante SAP-Hinweise:

  • 112312 - Einzelposten: Anzeige von Gegenkontoinformationen
  • 1034354 - FAGLL03: Anzeige von Gegenkontoinformationen
  • 1504612 - Einzelposten: Gegenkontoinformationen(BADI FI_ITEMS_CH_DATA)

 

Grundlagen

Öfter werde ich von Kunden oder auch Kollegen gefragt, wie denn die Gegenkontoinformationen in den Einzelpostenlisten (FBLxN, FAGLL03 usw.) ermittelt werden und wie man dies ggf. nachvollziehen oder gar beeinflussen kann:

 

Gegenkonto - das unbekannte Wesen...

Sofern die Hinweise 112312 bzw. 1034354/1504612 eingebaut wurden, lassen sich in den einschlägigen Einzelpostenanzeigen Gegenkontoinformationen einblenden, bestehend aus Gegenkontoart (S = Sachkonto, K = Kreditor, D = Debitor) und der Nummer des Gegenkontos.

Bei zweizeiligen Belegen ist die Auswahl des Gegenkontos ja eindeutig, d.h. bei einer Buchung

            Aufwand 100,--    an   Kreditor 100,--

ist die Gegenbuchung natürlich die jeweils andere Belegposition.

Bei drei- und mehrzeiligen Belegen muss ggf. eine Auswahl des Gegenkontos (nach Signifikanz) erfolgen:

Aufwand1 100,--

            Aufwand2 200,--

Aufwand3 300,--

Vorsteuer 60,--     an    Kreditor 660,--

 

Für die Ermittlung des Gegenkontos steht in der SAP Standardauslieferung der Funktionsbaustein GET_GKONT zur Verfügung. In diesem sind drei verschiedene Verfahren zur Bestimmung des signifikanten Gegenkontos implementiert - die Auswahl des Verfahrens erfolgt durch den Import-Parameter GKNKZ.

GKNKZ

Beschreibung

Ermitteltes Gegenkonto im o.g. Beispielbeleg (aus Sicht des kreditorischen Postens)

1

Es wird nur dann ein Gegenkonto zurückgeliefert, wenn es eindeutig ermittelt werden kann. Automatisch erzeugte Belegzeilen (wie bspw. Steuerzeilen) werden dabei ignoriert.

./.

2

Das betragsmäßig höchste Gegenkonto ohne Berücksichtigung automatisch generierter Belegzeilen wird zurückgeliefert.

Aufwand3

3

Das betragsmäßig höchste Gegenkonto mit Berücksichtigung automatisch generierter Belegzeilen wird zurückgeliefert.

Aufwand3

 

Werden zur Gegenkontoermittlung die weiter oben genannten Hinweise ohne Abwandlung implementiert, greift das Verfahren 3.

Erweiterung der bestehenden Verfahren

Kundenspezifische Ermittlungslogik

In vielen Fällen reicht die oben genannte Logik zur Gegenkontoermittlung aus. Im Einzelfall kann jedoch die Anforderung bestehen, den oben beschrieben Verfahren eigene, ausgefeiltere Methoden hinzuzufügen. Hierzu kann dann der Funktionsbaustein GET_GKONT in den Kundennamensraum kopiert (z.B. als Z_GET_GKONT) und anstelle des Standard-Bausteins an den entsprechenden Coding-Stellen in den Hinweisen 112312 bzw. 1034354 und 1504612 gerufen werden. Hierzu sind natürlich gewisse ABAP-Kenntnisse nötig.

Eine mögliche Anforderung könnte z.B. sein, dass als Gegenkonto von Sachkontenpositionen Kontokorrentpositionen grundsätzlich Vorrang haben sollen, auch wenn sie betragsmäßig kleiner sind als andersartige Gegenpositionen.

 

Beispiel:

Aufwand1 100,--

            Aufwand2 200,--

Aufwand3 300,--    an Kreditor 220,--

Vorsteuer 60,--            Kasse 440,--

 

Die Standard-Gegenkontoermittlung würde bei Abfrage des Gegenkontos aus Sicht eines der Aufwandskonten das Kassenkonto zurückliefern, weil es betragsmäßig signifikanter ist als die kreditorische Gegenposition. Genau hier soll aber ein „Override“ eingebaut werden, dass die Kontokorrentposition trotzdem Vorrang erhält. Das Verfahren erhält in unserem Beispiel die Kennzeichnung ‚4‘.

Hierzu passen wir die Form-Routine GKONT_ERMITTELN in unserer kundeneigenen Funktionsgruppe geeignet an:

*---- NEUES VERFAHREN 4 (wie 3, aber Vorfahrt für Kontokorrente)
WHEN '4'.
  IF BSEG-SHKZG = 'S'.
*   nur dann neu setzen, wenn Betrag höher ODER ein Kontokorrent daherkommt
*   UND nicht schon bereits ein Kontokorrent als Gegenkonto gesetzt ist
   IF BSEG-DMBTR > GKSUM_S OR BSEG-KOART CA 'DK' AND KOART_S CN 'DK'.

(Haben-Seite analog)

Das Beispielcoding aus den weiter oben genannten Hinweisen ist dann entsprechend anzupassen.

Beispiel-Coding aus Hinweis 1504612:

DATA: wa_items TYPE rfposxext.

LOOP AT ct_items INTO wa_items.

CALL FUNCTION 'Z_GET_GKONT'

  EXPORTING
     belnr = wa_items-belnr
     bukrs = wa_items-bukrs
     buzei = wa_items-buzei
     gjahr = wa_items-gjahr
     gknkz = '4'

  IMPORTING
     gkont = wa_items-gkont
     koart = wa_items-gkart
  EXCEPTIONS
     belnr_not_found = 1
     buzei_not_found = 2
     gknkz_not_found = 3
     OTHERS = 4.

IF sy-subrc = 0.
  MODIFY ct_items FROM wa_items.
ENDIF.

ENDLOOP.

Zusätzliche Gegenkontoinformationen

Eine immer wiederkehrende Anforderung in dem Themenkreis „Gegenkonto“ ist, dass zusätzlich zur Art und Nummer des Gegenkontos auch die entsprechende Bezeichnung anzeigbar gemacht werden soll. Hierzu lässt sich der Feldvorrat der Einzelpostenlisten um das Feld „Bez. Gegenkonto“ erweitern. Details dazu siehe hier, Abschnitt "Hinzufügen eigener Felder".

Es ist nun ein leichtes, nach erfolgreicher Gegenkontoermittlung anhand der Kontoart und der Nummer aus den entsprechenden Stammsatztabellen die Bezeichnung zu lesen und bereitzustellen.

Das obenstehende Beispielcoding kann dazu bspw. wie folgt erweitert werden:

CALL FUNCTION 'Z_GET_GKONT'
  EXPORTING
     belnr = wa_items-belnr
     bukrs = wa_items-bukrs
     buzei = wa_items-buzei
     gjahr = wa_items-gjahr
     gknkz = '4'

  IMPORTING
     gkont = wa_items-gkont
     koart = wa_items-gkart
  EXCEPTIONS
     belnr_not_found = 1
     buzei_not_found = 2
     gknkz_not_found = 3
     OTHERS = 4.

CASE wa_items_gkart. "das neue Feld heisse zzgkbez.

  WHEN ‚S‘.

    SELECT SINGLE txtmi INTO wa_items-zzgkbez FROM SKAT

      WHERE KTOPL = <Kontenplan>

       AND SAKNR = wa_items-gkont

       AND SPRAS = sy-langu.

  WHEN ‘K’.

    SELECT SINGLE name1 INTO wa_items-zzgkbez FROM LFA1

      WHERE LIFNR = wa_items-gkont.

  WHEN ‘D’.

    SELECT SINGLE name1 INTO wa_items-zzgkbez FROM KNA1

     WHERE KUNNR = wa_items-gkont.

ENDCASE.

 

Weiterlesen

Umrechnungsdatum beeinflussen

11. Oktober 2016 , Geschrieben von sapmandoo Veröffentlicht in #FI

Danke an Marek aus dem FICO-Forum.de, für's Erinnern an diese (manchmal) nützliche Funktion.

Ohne weiteres Zutun wird das Umrechnungsdatum im FI-Beleg aus dem Buchungsdatum abgeleitet, d.h. es wird der zum Buchungsdatum gültige Umrechnungskurs aus der TCURR verwendet. Möchte man dies (fallweise) nicht, kann dieses Systemverhalten mithilfe des BadIs FI_TRANS_DATE_DERIVE beeinflusst werden.

Das BadI ist filterabhängig und zwar vom Land (des Buchungskreises). Als Import-Parameter der Methode DERIVE_WWERT steht neben Buchungs- und Belegdatum, die Belegart zur Verfügung. Die Rückgabe des gewünschten Umrechnungsdatums erfolgt im Export-Parameter E_WWERT.

Codingbeispiel BadI-Implementierung:

METHOD if_ex_fi_trans_date_derive~derive_wwert.

*   Bei Belegart xy...
    IF i_blart = 'XY'.
*     Umrechnungsdatum auf Folgetag des Belegdatums setzen
      e_wwert = i_bldat + 1.
    ENDIF.

  ENDMETHOD.

Weitere Details finden sich im SAP-Hinweis 1670697 - FBCJ: BADI für Wertstellungsdatum

Weiterlesen

Beleg- / Referenznummernsuche im elektronischen Kontoauszug

13. Mai 2015 , Geschrieben von sapmandoo Veröffentlicht in #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).

Zudem werden hier ggf. auch die Kundenerweiterungen (BadI, Userexit, Details s. Hinweis 494777) durchlaufen.

 

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 Refereznummernsuche mithilfe der einschlägigen Erweiterungsmöglichkeiten implementiert werden.

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.

Weiterlesen

Vorerfassung mit BAPI BAPI_ACC_DOCUMENT_POST

4. März 2015 , Geschrieben von sapmandoo Veröffentlicht in #FI

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.

 

 

Weiterlesen

Veränderung der Buchungslogik im elektronischen Kontoauszug

24. März 2014 , Geschrieben von sapmandoo Veröffentlicht in #FI

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:

 

STYPE

Satztyp

K = Belegkopf

P = Belegposition

COUNT

Zähler für Belegkopf bzw. Belegzeile (Buchungsschnittstelle)

FNAM

Feldname Batch-Input

FVAL

Feldwert Batch-Input

(Beispielwert)

K

1

BKPF-BUDAT (Buchungsdatum)

01.03.2014

K

1

BKPF-BLDAT

(Belegdatum)

01.03.2014

K

1

BKPF-BUKRS

(Buchungskreis)

0001

K

1

P

1

BSEG-BSCHL

(Buchungsschlüssel)

40

P

1

BSEG-HKONT

(Sachkonto)

471100

P

1

BSEG-WRBTR

(Betrag in Belegwährung)

100,00

P

1

BSEG-ZUONR

(Zuordnung)

123456789

P

1

BSEG-SGTXT

Belegposition 1

P

1

P

2

BSEG-BSCHL

(Buchungsschlüssel)

50

P

2

BSEG-HKONT

(Sachkonto)

471200

P

2

BSEG-WRBTR

(Betrag in Belegwährung)

100,00

P

2

BSEG-ZUONR

(Zuordnung)

123456789

P

2

BSEG-SGTXT

Belegposition 2

P

2

 

 

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.

  DATAls_ftpost TYPE ftpost,
        l_string  TYPE string,
        ls_febre  TYPE febre,
        l_fees    TYPE string,
        l_brutto  TYPE DECIMALS 2,
        l_len     TYPE sy-index,
        l_count   TYPE count_pi.

  CONSTANTSlc_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 strlenl_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.

Weiterlesen

Valutadatum 30.Feb. im elektronischen Kontoauszug MT940

10. März 2014 , Geschrieben von sapmandoo Veröffentlicht in #FI

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!
DATAcheck_datum(6TYPE c.
DATAls_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.

 

 

 

 

 

 

 

 

 

 

Weiterlesen

Erweiterung der Einzelpostenanzeige um zusätzliche Felder

20. Februar 2014 , Geschrieben von sapmandoo Veröffentlicht in #FI

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.  

     

Welche Felder stehen standardseitig (d.h. ohne weiteres Zutun) zur Verfügung?

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:

Einzelposten-Tabelle

Bedeutung

Basis für Transaktion

BSID

Debitorische offene Posten

FBL5N

BSAD

Debitorische ausgeglichene Posten

FBL5N

BSIK

Kreditorische offene Posten

FBL1N

BSAK

Kreditorische ausgeglichene Posten

FBL1N

BSIS

Sachkonten – offene Posten

(Achtung: Einzelposten werden nur fortgeschrieben, wenn im jeweiligen Sachkontenstammsatz die Option „Einzelpostenanzeige“ aktiviert ist)

FBL3N bzw. FAGLL03

BSAS

Sachkonten – ausgeglichene Posten

(Achtung: Einzelposten werden nur fortgeschrieben, wenn im jeweiligen Sachkontenstammsatz die Option „Einzelpostenanzeige“ aktiviert ist)

FBL3N bzw. FAGLL03

 

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.

 

Verwendung von Sonderfeldern

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.

      

Hinzufügen eigener Felder

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

 

Erweiterung über BadI FAGL_ITEMS_CH_DATA (Transaktionen FBLxN und FAGLL03)

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.

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

Weiterlesen

Ausgabe von Mahnungen und Zahlungsavisen per EMail o. Fax

10. September 2013 , Geschrieben von sapmandoo Veröffentlicht in #FI

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!

Weiterlesen
1 2 > >>