Overblog
Folge diesem Blog
Administration Create my blog
11. Oktober 2016 2 11 /10 /Oktober /2016 08:49

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

Published by sapmandoo - in FI
Kommentiere diesen Post
17. März 2016 4 17 /03 /März /2016 10:10

Mithilfe der KS04 lassen sich Kostenstellen löschen. Blöd nur, dass dabei immer nur eine spezifiziert werden kann und man aber z.B. 100 fehlerhaft angelegt (noch nicht bebuchte!) KST löschen will.

Anbei ein kleines Programm, welches sich des BAPIs BAPI_COSTCENTER_DELETEMULTIPLE bedient. Der Baustein durchläuft dabei die gleichen Prüfungen, die auch beim Löschen im Dialog (KS04) ausgeführt werden. Entsprechend lange wird die Laufzeit sein.

REPORT Z_KS04_MEHR_ALS_EINE.
* Löschen von mehreren Kostenstellen
TABLES: CSKS.
DATA: LT_CLIST TYPE TABLE OF BAPI0012_CCDELLIST.
DATA: LT_RETURN TYPE BAPIRET2_TAB.

PARAMETERS: pa_kokrs like csks-kokrs obligatory.
SELECT-OPTIONS: so_kostl for csks-kostl.
* hier ggf. noch weitere Selektionskriterien einfügen...

START-OF-SELECTION.
  SELECT * FROM CSKS INTO CORRESPONDING FIELDS OF TABLE LT_CLIST
     WHERE kokrs = pa_kokrs
     AND kostl in so_kostl.

CALL FUNCTION 'BAPI_COSTCENTER_DELETEMULTIPLE'
    EXPORTING
        controllingarea  = pa_kokrs
        testrun         = 'X'       "TESTLAUF-Kz. raus, wenn's ernst wird
      TABLES
        COSTCENTERLIST       = lt_clist
        return               = lt_return
    EXCEPTIONS
      error_message   = 1.
IF SY-SUBRC <> 0.
  MESSAGE 'Mind. eine KST muckt auf, Details s. Protokoll'.
ENDIF.

* Ausgabe Meldungen
 CALL FUNCTION 'C14ALD_BAPIRET2_SHOW'
    TABLES
      i_bapiret2_tab = lt_return.
Published by sapmandoo - in CO
Kommentiere diesen Post
26. Januar 2016 2 26 /01 /Januar /2016 14:11

Bestimmte CO-Objekte (wie z.B. Innenaufträge) lassen sich im SD Auftrag im SAP Standard nur auf Positionsebene kontieren, was natürlich nervt, wenn bei allen Positionen das gleiche CO-Objekt eingetragen werden soll.

Kann man aber mithilfe der einschlägigen Userexits im Include MV45AFZB was machen:

1. Schritt:

Gewünschtes CO-Objekt "aufmachen" (Im Standard ist nur PSP-Element im Auftragskopf kontierbar).

z.B. Innenauftrag:

FORM USEREXIT_COBL_SEND_HEADER.

*  This example shows how to select fields that are shown in the
*  account assignment block

*  INT_COBLF-FDNAM = zzfield1.  "hier: 'AUFNR' 
*  INT_COBLF-OUTPUT = '1'.
*  IF T180-TRTYP NE CHARA AND
*     VBAP-KZVBR NE KZVBR_P.
*    INT_COBLF-INPUT    = '1'.
*    INT_COBLF-REQUIRED = '1'.  "nur wenn Mussfeld!!!!
*  ENDIF.
*  INT_COBLF-ACTIVE = '1'.
*  APPEND INT_COBLF.
 ENDFORM.

2. Schritt:

Auftragsnummer in Auftragskopf (VBAK) speichern:

FORM USEREXIT_COBL_RECEIVE_VBAK.

* VBAK-zzfield = COBL-zzfield2. 
 "hier: vbak-aufnr = cobl-aufnr.

ENDFORM.

3. Schritt

Objekt in die Auftragspositionen "vererben":

FORM USEREXIT_MOVE_FIELD_TO_COBL USING US_VBAK STRUCTURE VBAK
                                       US_VBAP STRUCTURE VBAP
                              CHANGING CH_COBL STRUCTURE COBL.

* Examples
* CH_COBL-zzfield = US_VBAK-zzfield2.
* CH_COBL-zzfield = US_VBAP-zzfield2.
"hier: ch_cobl-aufnr = us_vbak-aufnr.
ENDFORM.
Published by sapmandoo - in SD CO
Kommentiere diesen Post
13. Mai 2015 3 13 /05 /Mai /2015 09:48

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_VERWENDNGSZWECK (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_VERWENDNGSZWECK

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

Published by sapmandoo - in FI
Kommentiere diesen Post
20. April 2015 1 20 /04 /April /2015 17:41

Der nachfolgende Link, enthält eine Anleitung, wie mithilfe der Ordnungsbegriffe bzw. der SAP-Erweiterung AIST0002 kundeneigene Felder zum Anlagenstammsatz hinzugefügt werden können:

https://drive.google.com/file/d/0B1_CTm8mzZEQdS1JZUUtNG9YbTQ/view?usp=sharing

Published by sapmandoo - in AA
Kommentiere diesen Post
4. März 2015 3 04 /03 /März /2015 15:58

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.

 

 

Published by sapmandoo - in FI
Kommentiere diesen Post
10. Februar 2015 2 10 /02 /Februar /2015 13:55

In der Bewertungspraxis des Handels wird zur Jahresendbewertung häufig das Verfahren der ‚verlustfreien Bewertung’ angewendet. Dabei wird dem Bewertungspreis eines Artikels (z.B. dem gleitenden Durchschnittspreis) zum Bewertungsstichtag ein sog. Vergleichswert gegenüber gestellt, dem üblicherweise ein realer oder fiktiver Verkaufspreis zugrunde liegt. Dabei werden in vielen Fällen vom Verkaufspreis noch im Rahmen der Warenveräußerung anfallende Kostenbestandteile abgezogen. Der hieraus resultierende Wertansatz wird als beizulegender Wert bezeichnet.

Das hier skizzierte Verfahren findet insbesondere in solchen Branchen Anwendung, bei denen im Verlauf des Betrachtungszeitraums erhebliche Preisreduktionen der angebotenen Artikel, z.B. im Rahmen von Ausverkäufen stattfinden (Saisonware, Mode, Möbel). Die Grundannahme bzw. -idee ist hierbei, dass in bestimmten Fällen der Verkaufspreis eines Artikels während seines Lebenszyklus so weit reduziert wird/werden muss, dass beim Verkauf die Selbstkosten nicht mehr gedeckt werden. Dies bedeutete, dass beim jedem Verkauf eines solchen Artikels ein Verlust entstünde, der durch die vorzunehmende Abwertung jedoch ‚antizipiert‘ wird und die Bewertung somit auch bei derartigen Preisnachlässen ‚verlustfrei‘ bleibt.

 

Zur Ermittlung des Vergleichswerts gibt es in SAP kein Standardverfahren, die gewünschte Logik muss komplett als Eigenentwicklung implementiert werden. Hierzu stellt SAP die Erweiterung NIWE0003 (Funktionsexit EXIT_SAPLNIW3_001) zur Verfügung. In neueren Releases ist die vorgenannte Erweiterung auslieferungsseitig bereits in die BAdI-Definition SMOD_NIWE0003 migriert worden.

 

Maßgeblich für sinnvolle Anwendbarkeit dieses Verfahrens ist demnach die Ermittlung des Vergleichspreises, also des beizulegenden Wertes. Ausgangsbasis ist dabei der voraussichtliche Verkaufserlös, d.h., bezogen auf einen Artikel, der zum Bewertungsstichtag anzusetzende Verkaufspreis. Oft liegt dieser bereits als Verkaufspreiskondition vor, wenn die Preisreduzierungen in Form von Aktionen oder geplant (Stichwort ‚Preisplanung‘) stattfinden. In diesen Fällen könnte der Verkaufspreis mithilfe der im System abgelegten Konditionen (z.B. mit Funktionsbaustein SALES_PRICE_READ) ermittelt werden. Im Sinne des sog. Wertaufhellungsprinzips kann dabei das Preisdatum entscheidend sein. Wenn bspw. der Bewertungsstichtag der 31.12. ist, jedoch der Bewertungslauf im Rahmen der Abschlusserstellung erst Anfang Februar erfolgt, könnte der Verkaufspreis Im Januar nochmals angepasst worden sein. Es empfiehlt sich daher, immer den aktuell gültigen Konditionssatz heranzuziehen.

 

Bei der Bewertung nach den Verhältnissen vom Absatzmarkt wird der mit den Anschaffungs- oder Herstellungskosten der fertigen und unfertigen Erzeugnisse und der Waren zu vergleichende Wert retrograd ermittelt. Hierbei wird also vom späteren Erlös ausgegangen. Deshalb wird diese Bewertungsmethode als retrograde Bewertung bezeichnet

 

Es wird von folgendem Schema ausgegangen:

Retrograde Bewertung

 

voraussichtlicher Verkaufserlös

./.

Erlösschmälerungen

./.

Verpackungskosten und Ausgangsfrachten

./.

allgemeine Vertriebskosten

./.

Verwaltungskosten

./.

Kapitaldienstkosten (für Lagerung bis zum Verkauf)

=

am Abschlussstichtag beizulegender Wert

Hierbei werden die für den Verkauf bestimmten Vorräte so bewertet, dass nach dem Abschlussstichtag kein Verlust mehr entsteht. Ein beim Verkauf voraussichtlich entstehender Verlust wird durch die Bewertung zum Abschlussstichtag in die Periode vorgezogen.

Nach der Rechtsprechung des BFH ist der Wert anzusetzen, der von dem voraussichtlich erzielbaren Veräußerungserlös nach Abzug des nach dem Bilanzstichtag noch anfallenden betrieblichen Aufwands und des durchschnittlichen Unternehmergewinns verbleibt.

 

Verkaufserlös:
Der voraussichtlich nach dem Bilanzstichtag zu erzielende Erlös. Dabei dürfen auch konkret zu erwartende Preissteigerungen berücksichtigt werden.

Erlösschmälerungen:
Preisnachlässe wie z.B. Skonti und Mengenrabatte.

Allgemeine Vertriebskosten:
Provisionen und Lizenzgebühren, die beim Verkauf entstehen. Vertriebsgemeinkosten, spätere Montage- und Aufstellungskosten, Garantierisiken.

Verwaltungskosten:
Kosten der Lagerhaltung und -verwaltung, Abrechnungskosten sowie Kosten für Zahlungseingang. Auch Zinsverluste in Form von Fremdkapitalkosten wegen voraussichtlich längerer Lagerung der Bestände sind einzubeziehen.

Allgemein:
Die zukünftigen Kosten sind nach der Vollkostenmethode bei Normalbeschäftigung zu ermitteln, also Einzelkosten und anteilige Gemeinkosten.

 

Der jeweils niedrigere Ansatz wird im Sinne des Niederstwertprinzips als Bewertungspreis herangezogen.

Published by sapmandoo - in MM
Kommentiere diesen Post
27. August 2014 3 27 /08 /August /2014 10:07

Für die maschinelle Verbuchung von CO-Buchungen stehen neben der Übernahmetransaktion BATCHMAN (vgl. Artikel Übernahme von externen Umbuchungen und statistischen Kennzahlen ins CO ) auch div. BAPIs zur Verfügung. Nachfolgend ein Beispiel für die Verwendung des BAPIs BAPI_ACC_ACTIVITY_ALLOC_POST, mit dem Leistungsverrechnungen (KB21N) gebucht werden können:

 

*&---------------------------------------------------------------------*
*& Report  ZTEST_KB21N_BAPI
*&
*&---------------------------------------------------------------------*
*& Demo-Programm BAPI-Aufruf BAPI_ACC_ACTIVITY_ALLOC_POST
*&                           Leistungsverrechnung (KB21N)
*&---------------------------------------------------------------------*

REPORT ztest_kb21n_bapi.

DATAls_doc_header TYPE bapidochdrp.
DATAlt_doc_items  TYPE TABLE OF bapiaaitm,
      ls_doc_item   TYPE bapiaaitm,
      lt_return     TYPE TABLE OF bapiret2.
DATAls_docno      TYPE bapidochdrp-doc_no.

* Belegkopf
ls_doc_header-co_area     '1000'.         "Kostenrechnungskreis
ls_doc_header-docdate     sy-datum.       "Belegdatum
ls_doc_header-postgdate   sy-datum.       "Buchungsdatum
ls_doc_header-doc_hdr_tx  'Demo'.         "Belegkopftext
ls_doc_header-username    sy-uname.       "User-Name

* Positionen aufbauen
* Pos. 1
ls_doc_item-send_cctr     '0000002047'.   "Sender-Kostenstelle
ls_doc_item-acttype       '8'.            "Leistungsart
ls_doc_item-actvty_qty    3.              "Menge
ls_doc_item-rec_cctr      '0000002013'.   "Empfänger-KST
APPEND ls_doc_item TO lt_doc_items.

* Pos. 2
ls_doc_item-send_cctr     '0000002047'.
ls_doc_item-acttype       '8'.
ls_doc_item-actvty_qty    10.
ls_doc_item-rec_cctr      '0000002004'.
APPEND ls_doc_item TO lt_doc_items.

* BAPI rufen
CALL FUNCTION 'BAPI_ACC_ACTIVITY_ALLOC_POST'
  EXPORTING
    doc_header      ls_doc_header
*   IGNORE_WARNINGS = ' '
  IMPORTING
    doc_no          ls_docno
  TABLES
    doc_items       lt_doc_items
    return          lt_return
*   CRITERIA        =
*   CUSTOMER_FIELDS =
  .

* COMMIT nicht vergessen!
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.

* Meldungen ausgeben
IF lt_return[] IS NOT INITIAL.
  CALL FUNCTION 'C14ALD_BAPIRET2_SHOW'
    TABLES
      i_bapiret2_tab lt_return.
ENDIF.

Published by sapmandoo - in CO
Kommentiere diesen Post
24. März 2014 1 24 /03 /März /2014 15:38

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.

Published by sapmandoo - in FI
Kommentiere diesen Post
10. März 2014 1 10 /03 /März /2014 17:28

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.

 

 

 

 

 

 

 

 

 

 

Published by sapmandoo - in FI
Kommentiere diesen Post