SAPManDoo - SAP Resource

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.

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.

DATA: ls_doc_header TYPE bapidochdrp.
DATA: lt_doc_items  TYPE TABLE OF bapiaaitm,
      ls_doc_item   TYPE bapiaaitm,
      lt_return     TYPE TABLE OF bapiret2.
DATA: ls_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.

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.

Nachfolgend eine Anleitung, wie zum einen Primärkostenumbuchungen und zum anderen statistische Kennzahlen mithilfe von Standard-Werkzeugen ins CO übernommen werden können. Grundlage hierfür bilden entsprechend vorformatierte Excel-Dateien. Die Übernahme selbst erfolgt jeweils mit der CO-spezifischen Datenübernahmetransaktion BATCHMAN.    

Details zum Vorgehen befinden sich im Dokument https://docs.google.com/file/d/0B1_CTm8mzZEQamdDMW5Xa3BzSWc/edit

Das hier beschriebene Verfahren fusst auf der Standard-Auslieferung von SAP für das hinter dem BATCHMAN verankerte BadI. Eine eigene, gepimpte Version steht hier zur Verfügung

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.

Ein Artikel aus der Serie: 'Ihr sollt es im Leben mal besser haben, als ich...':

Symptom:
Es wurden im CO-PA neue Wertfelder (oder Merkmale) angelegt. Diese sollen nun dem Ergebnisbereich hinzugefügt werden. Die neuen Wertfelder lassen sich nicht auswählen, obwohl sie aktiviert sind.

Ursache:
In der Routine set_rky_tab_pick im Include MKCGGF81 wird das Kennzeichen 'Pick' in der Tabelle rky_tab gesetzt, welches steuert, ob ein Wertfeld auswählbar ist oder nicht. Im ersten Coding-Abschnitt werden alle die Wertfelder auf 'nicht auswählbar' gesetzt, die bereits dem Ergebnisbereich zugeordnet sind... (das ist ja auch soweit nachvollziehbar!).

Im nachfolgenden Coding-Abschnitt wird aber eine zusätzliche, perfide, nicht weiter dokumentierte Prüfung vorgenommen:

   if cgg_par-ffgrp        eq kcdb_false  and
      ikcge-eq_txt_allowed eq kcdb_false.
     loop at kyf_tab into  kyf_wa
                     where txt_m eq rky_wa-txt_m
                     or    txt_s eq rky_wa-txt_s.
       exit.
     endloop.
     if sy-subrc eq 0.
       clear rky_wa-pick.
     endif.
   endif.

Hier wird der Mittel- und Kurztext der Wertfelder im Vorrat mit denen der bereits im Ergebnisbereich vorhandenen Wertfelder (Tab. kyf_tab) abgeglichen. Stimmt einer der Texte überein, wird das Feld PICK auf space gesetzt.

D.h. es können keine zwei Wertfelder mit gleichen (Kurz-)texten im Ergebnisbereich verwendet werden.

Der im Coding abgefragte Paramter 'eq_txt_allowed' ist immer hart auf SPACE gesetzt - die (nicht im Customizing beeinflussbare) Initialisierung erfolgt in der Routine init_ikcge_ke im Include FKCGNF20.

Ich hab's nicht überprüft, aber ich gehe davon aus, dass das Gesagte analog auch für Merkmale gilt.

Hat mich einige Mühe gekostet, dass herauszufinden, deshalb die Info an Euch, falls Ihr mal vor dem gleichen Phänomen steht.

Um eine Abrechnungsvorschrift zu einem Innenauftrag automatisiert anzulegen, sollte in neueren Releases die Standardfunktionalität "automatische Generierung von Abrechnungsvorschriften" verwendet werden. Hierüber steht ein umfassendes Framework zur Verfügung, mit dem die meisten Use-Cases abgedeckt sein sollten. Details hierzu finden sich im Customizing-Leitfaden unter Controlling - Innenaufträge - Istbuchungen - Abrechnung - Automatische Generierung von Abrechnungsvorschriften ...

Für Datenübernahmen von Innenaufträgen, d.h. Übernahme der Stammdaten inkl. Abrechnungsvorschrift kann der BAPI BAPI_INTERNALORDER_CREATE verwendet werden.

Sollte es in Ausnahmefällen jedoch nötig sein, per Programm Abrechnungsvorschriften zu bestehenden Innenauftragen zu generieren, steht der Funktionsbaustein: K_ORDER_SRULE_ADD  zur Verfügung, der allerdings einen großen Nachteil hat: er wurde von SAP in neueren Releases deaktiviert, d.h. im Coding ist ein sofortiger Rücksprung zur rufenden Anwendung implementiert, der jegliche Ausführung unterbindet:

************************************************************
************************************************************

  RETURN. "fm will be deleted within the next releases ...

************************************************************
************************************************************

D.h., um ihn zu verwenden, muss entweder der oben stehende Befehl per Modifikation ausgebaut oder eine Kopie des Funktionsbausteins im Kundennamensraum angelegt werden.

Schade eigentlich, denn der Funktionsbaustein werkelt gut.

Der FuBa kann wie folgt gerufen werden:

*&---------------------------------------------------------------------*
*& Report  YDEMO_ORDER_SRULE_ADD
*&
*&---------------------------------------------------------------------*
*& maschinelles Anlegen einer Abrechnungsvorschrift zu CO-Innenaufträgen
*&---------------------------------------------------------------------*
REPORT ydemo_order_srule_add.

* Schnittstelle f. BAPI
DATA: l_objnr     LIKE aufk-objnr.            "Objektnummer

DATA:
*     Tabelle mit Abrechnungsvorschriften
      lt_srules   TYPE TABLE OF srules_ext,
*     Tabelle f. Übergabe CO-PA Felder bei Abrechnung ins Ergebnis
*     Angabe der Tabelle ist Pflicht, auch wenn nicht ins CO-PA
*     abgerechnet werden soll...
      lt_criteria TYPE TABLE OF bapi_copa_data,
      l_rule_inserted LIKE sy-batch.

DATA: ls_srule    TYPE srules_ext.

* Objektnummer zusammenbauen oder für einen gegebenen Innenauftrag
* einfach aus der Tab. AUFK nachlesen (Feld AUFK-OBJNR)
* Zusammenbauen ist aber auch recht einfach:
*   Format Objektnummer f. CO-Aufträge: XX999999999999
*   XX           = Objektart OR
*   999999999999 = 12-stellige Innenauftragsnummer
l_objnr(2) = 'OR'.
l_objnr+2(12) = '000000400000'.

* Abrechnungsvorschrift zusammenbasteln...

* Abrechnungsart (engl. Festwerte)
*   z.B. FUL = Gesamtabrechnung
*        PER = periodische Abrechnung
ls_srule-settl_type    = 'PER'.

* ls_srule-SOURCE                      "opt: Ursprungszuordnung

* Aufteilung
ls_srule-percentage    = 100.          "prozentuale Aufteilung ODER
*ls_srule-equiv_number                 "Äquivalenzziffer       ODER
*ls_srule-amount                       "Betrag f. Betragsabrechnung

* Das Abrechungsempfängerobjekt ergibt sich aus der selektiven
* Befüllung der folgenden Felder:
*ls_srule-bus_area                     "Geschäftsbereich
*ls_srule-comp_code                    "Buchungskreis
*ls_srule-gl_account                   "Sachkonto
*ls_srule-profit_ctr                   "Profitcenter
ls_srule-costcenter    = '0000002001'. "Kostenstelle
*ls_srule-orderid                      "Innenaauftrag
*ls_srule-wbs_element                  "PSP-Element
*ls_srule-asset_no                     "Anlage
* ...

APPEND ls_srule TO lt_srules.

CALL FUNCTION 'K_ORDER_SRULE_ADD'
  EXPORTING
    object_no            = l_objnr
  IMPORTING
    flg_rule_inserted    = l_rule_inserted
  TABLES
    srules               = lt_srules
    criteria             = lt_criteria
  EXCEPTIONS
    wrong_input          = 1
    error_occurred       = 2
    object_not_found     = 3
    activity_not_allowed = 4
    OTHERS               = 5.
IF sy-subrc <> 0.
  WRITE: / 'Fehler', sy-subrc, 'beim Anlegen der Abrechnungsvorschrift'.
ELSE.
  IF l_rule_inserted = 'X'.
    WRITE: 'Abrechnungsvorschrift hinzugefügt'.
    COMMIT WORK.
  ELSE.
    WRITE: 'Abrechnungsvorschrift nicht hinzugefügt'.
  ENDIF.
ENDIF.

Im nachfolgenden Link ist eine ausführliche Anleitung enthalten, wie Fremddaten ohne Entwicklungsaufwand ins CO-PA geladen werden können:

https://drive.google.com/file/d/0B1_CTm8mzZEQTkowLXRwSDRhYVU/edit?usp=sharing

Viel Erfolg!

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!