basis-entwicklung allg.

Wer schon mal im Customizing der Budgetierung, speziell im Bereich der Verfügbarkeitskontrolle unterwegs war (z.B. im Kontext Projektcontrolling oder Investitionsmanagement), wird beim Einstellen der Toleranzen festgestellt haben, dass man bei Überschreitung einer gewissen Budget-Ausschöpfung die Auswahl zwischen drei System-Aktionen hat:

• Warnung
• Fehlermeldung
• Warnung mit Mail an den Verantwortlichen

Beim Punkt "Warnung mit Mail an Verantwortlichen" kamen (zumindest bei mir) etliche Fragen auf, z.B.:

• Wer ist dieser Verantwortliche in diesem Zusammenhang?
• Wohin wird die Mail eigentlich geschickt?
• Was steht da genau drin?
• Kann man das irgendwie beeinflussen?
• Warum habe ich nix anständiges gelernt...?

Der für das jeweilige PSP-Element bzw. für den Innenauftrag Verantwortliche wird in den Stammdaten zugeordnet. Während bei den Innenaufträgen direkt der entsprechende SAP-User im Feld "Verantwortlicher Benutzer" eingetragen wird...

... wird beim PSP-Element der Verantwortliche mit Schlüssel und Klarnamen im Customizing definiert und dort der korrespondierende SAP-User zugeordnet.

Im Stammsatz des PSP-Elementes selbst, wird dann der Schlüssel hinterlegt:

Für den Fall, dass man im Customizing der Toleranzen die Aktion "Warnung mit Mail an Verantwortlichen" ausgewählt hat aber zu einem Objekt KEIN Verantwortlicher gepflegt ist, wird aus der Warnung eine Fehlermeldung (natürlich ohne Mail, an wen auch...?).

Ohne weiteres Zutun wird die "Mail" als interne SAP-Office-Nachricht an den Business Workplace des jeweiligen verantwortlichen SAP-User gesendet.

Die Nachricht ist dabei wie folgt aufgebaut:

Das funktioniert soweit gut, d.h. wem das genügt, braucht hier nichts weiter einzustellen. Vermutlich wird man sich jedoch einigen weitergehenden Anforderungen gegenüber sehen, z.B. den Inhalt oder Betreff der Mail zu beeinflussen oder die Nachricht als "richtige" Mail an ein externes Mail-System zu senden. 

Per Customizing geht hier leider nix. Aber es gibt eine SAP-Erweiterung, mit der man z.B. die Mail-Adressaten überschreiben und die interne Nachricht in eine externe Mail "umwandeln" kann.

Zudem gibt es einen Userexit, mit dem gewisse Eigenschaften der Mail verändert werden können. So kann z.B. ein Verfallsdatum hinzugefügt oder der Betreff angepasst werden. Der Inhalt, d.h. der Text der Mail ist leider ohne Modifikation nicht beeinflussbar, dazu aber später mehr. 

SAP-Erweiterung zur Bestimmung des/der Mailempfänger/s

Beispiel-Coding:

*&---------------------------------------------------------------------*
*& Include          ZXBPFCU01
*&---------------------------------------------------------------------*
* in standard, the message will be sent to the business workplace of
* the SAP user, that is assigned as responsible for the PSP
* element or internal order. We want to send the warning mail
* to the responsible user's regular mail account (e.g. Outlook)

DATA: lt_return  TYPE TABLE OF bapiret2,
      lt_addsmtp TYPE TABLE OF bapiadsmtp.

* In case, responsible in the master data of the PSP element or
* int. order is not maintained, this table is empty and an error
* message will be thrown in the calling application.
CHECK t_mail_receivers[] IS NOT INITIAL.

* As only one responsible can be assigned, we take the first entry
READ TABLE t_mail_receivers INDEX 1 ASSIGNING FIELD-SYMBOL(<ls_mail_receiver>).
CHECK sy-subrc = 0 AND <ls_mail_receiver> IS ASSIGNED.

* Now we replace the SAP-User with the external EMail address. We retrieve
* that from their user data.

* Switch recipient adress type to external email address:
<ls_mail_receiver>-recesc = 'U'.

* Retrieve & set Email-Adress
CALL FUNCTION 'BAPI_USER_GET_DETAIL'
  EXPORTING
    username = <ls_mail_receiver>-recnam
  TABLES
    return   = lt_return
    addsmtp  = lt_addsmtp.

CHECK lt_addsmtp[] IS NOT INITIAL.
READ TABLE lt_addsmtp INDEX 1 ASSIGNING FIELD-SYMBOL(<ls_addsmtp>).
IF sy-subrc = 0 AND <ls_addsmtp> IS ASSIGNED.
  <ls_mail_receiver>-recextnam = <ls_addsmtp>-e_mail.
ENDIF.

Die Tabelle T_MAIL_RECEIVERS darf dabei auch mehrere Empfänger enthalten. Um bspw. CC oder BCC-Empfänger hinzuzufügen, sind die Tabellenfelder SNDBC (BCC) bzw. SNDCP (CC) des entsprechenden Eintrags mit 'X' zu belegen.

Userexit

Im Hinweis 879732 wird ein Userexit beschrieben, mit dem gewisse Mail-Attribute beeinflusst werden können. Nachfolgend einige Coding-Beispiele für typische Anwendungsfälle.

*&---------------------------------------------------------------------*
*& Subroutinenpool ZMAILHDR
*&---------------------------------------------------------------------*
*& Change mail properties for mails created by availability control
*& See SAP-Note 879732 for details
*&---------------------------------------------------------------------*
PROGRAM zmailhdr.

FORM mail_header_adjust
  CHANGING c_sood1 LIKE sood1.
* Adjust header of mails sent along with warnings
* of availability control.

** Example: Determine an expiry date.
** Option 1 - Expiry date = end of this year.
*  C_SOOD1-DLDAT+0(4) = SY-DATLO(4).
*  C_SOOD1-DLDAT+4(4) = '1231'.
** Option 2 - Expiry date = current date + 4 weeks.
*  C_SOOD1-DLDAT = SY-DATLO + 28.

** Example: Change Mail subject
*  c_sood1-OBJDES = 'My subject'.

ENDFORM.

Mail-Inhalt

Der Inhalt der Mail ist leider nicht ohne Modifikation veränderbar. Es wird hierbei der Langtext der entsprechenden Warnmeldung, die bei der Belegerfassung geworfen wird, verwendet und noch um gewisse hart codierte Bestandteile ergänzt.

Falls es doch jemand anpassen will/muss: Der Zusammenbau des Textes findet im Funktionsbaustein BP_CREATE_MAIL, Zeilen 94ff statt.

In neueren Releases wird die Nachbearbeitung der elektronischen Kontoauszüge (zumindest bei den noch immer zahlreich vorhandenen Fans des SAP-GUI) gerne mithilfe der Transaktion FEB_BSPROC erledigt. Sie kann zugegebenermaßen nicht alles, was die korrespondierende FIORI-App drauf hat (z.B. die Definition eigener Buchungsregeln während der Bearbeitung), aber sie verrichtet nach wie vor zuverlässig ihren Dienst in vielen Bankbuchhaltungsabteilungen.

Ab und zu wurde ich in der Vergangenheit gefragt, ob kundeneigene Informationen in irgendeiner Form (modifikationsfrei!) in die beliebte GUI-Transaktion integriert bzw. in ihr dargestellt werden können. Daraufhin habe ich mich mal damit beschäftigt und zu meiner Überraschung tatsächlich nur einen BTE gefunden, der in diese Richtung zielt.

Es ist z.B. leider nicht möglich, die Arbeitsliste mit den Einzelsätzen im oberen Bereich der Transaktion um eigene, d.h. nicht in der Tabelle FEBEP vorhandene Felder zu erweitern.

Es ist jedoch möglich, im unteren Abschnitt der Transaktion einen eigenen Reiter mit entsprechendem Subscreen einzufügen, in dem kundeneigene Informationen ermittelt/berechnet und dargestellt werden können (hier als Beispiel "Saldo"):

Dies lässt sich mit dem Business Transaction Event 00002340 (P&S-Schnittstelle) bewerkstelligen.

Informationen zu Implementierung von BTEs finden sich u.a. hier.

Im konkreten Fall wird der Musterfunktionsbaustein zum o.g. BTE (SAMPLE_INTERFACE_00002340) in den Kundennamensraum kopiert und die Exportparameter mit folgenden Daten versorgt: 

  e_dynnr = '0100'.
  e_repid = 'SAPLZBTE'.
  e_appl_tab_title = 'Saldo'.

  gs_febep = i_febep.

Sofern Daten aus der Anwendung zur Bereitstellung der gewünschten Informationen im Subscreen benötigt werden, können diese hier in das globale Gedächtnis der Funktionsgruppe kopiert werden, damit auf diese später im Dynpro zugegriffen werden kann (hier bspw. der Inhalt des aktuell bearbeiteten Einzelsatzes).
 

Der Ausgestaltung des Subscreens sind nun kaum noch Grenzen gesetzt und hängt natürlich von der konkreten Anforderung ab. Ich hatte mal eine Anfrage, bei der es dem Anwender ermöglicht werden sollte, das Hauptbuch während der Bearbeitung mit den bereits verbuchten Auszugspositionen abzustimmen. Hierzu sollte der Saldo des Bankkontos 'realtime' dem Saldo des Kontoauszugs gegenübergestellt werden. Letztendlich ist es hierbei nicht zu einer Umsetzung gekommen, deshalb ist das unten aufgeführte Beispiel noch im "Mock-Up"-Status...

Generell ist die ALE-Schnittstelle für FI-Belege (FIDCC1/2) ziemlich restriktiv, was die Verteilung von Sonderhauptbuchbelegen angeht. Im SAP-Hinweis 114814, Punkt 14. wird darauf explizit eingegangen:

Auszug aus HW 114814:

14. Sonderhauptbuchvorgänge SHBV
-------------------------------

Sonderhauptbuchvorgänge sind:

• Anzahlungen
• Anzahlungsanforderungen
• Wechsel
• sonstige

Beim SAP-Verteilungsszenario für FI-Belege wird davon ausgegangen, daß es sich bei den dezentralen Sender-Systemen um z.B. Logistik-Systeme handelt. Das zentrale Empfänger-System ist das FI-Buchhaltungssystem, in dem alle operativen Prozesse, wie Zahlen, Mahnen usw., stattfinden.
Unter dieser Voraussetzung erscheint das Buchen von Belegen mit Sonderhauptbuchvorgängen (SHBV), ausgenommen Anzahlungsanforderungen, nur im zentralen System sinnvoll. Mit anderen Worten, es besteht keine Notwendigkeit, SHBV in den dezentralen Systemen zu buchen und per ALE zu versenden.

Deshalb wird im SAP-Standard das Versenden von SHBV aus einem dezentralen System heraus nicht unterstützt.
Ist der Nachrichtentyp FIDCC1 oder FIDCC2 aktiv, ist es zwar möglich, im dezentralen System Belege mit SHBV zu buchen und auch zu versenden (außer Anzahlungsanforderungen), aber es ist nicht gewährleistet, daß im Empfängersystem aus diesem IDoc erfolgreich ein FI-Beleg gebucht werden kann.
Versendet der Anwender trotzdem SHBV aus dem dezentralen System, liegt es in seiner Verantwortung und Kontrolle, daß der SHBV-Beleg im Empfängersystem auch erfolgreich, vollständig und richtig verbucht wird.

Ursachen für eventuell auftretende Fehler sind:

• Der FI-Beleg und das daraus resultierende IDoc beinhalten u.U. nicht alle notwendigen Felder. Z.B. fehlt für den SHBV 'Wechsel' die Struktur BSED.
• Die RW-Schnittstelle zum Buchen der IDOC-Belege kann nicht alle SHBV verarbeiten, weil die entsprechenden Felder in den Übergabestrukturen ACCIT usw. fehlen. 'Wechsel' werden beispielsweise im RWIN sofort abgewiesen mit der Fehlermeldung: F5 246 Sonderhauptbuchvorgänge der Klasse W werden nicht unterstützt.

(Technisch: In der RW-Schnittstelle werden SHBV-Belege mit BSEG-UMSKS='W' und BKPF-BSTAT='S' nicht verbucht.)

Allerdings kann man in der Regel bei einer reinen FI-Buchung davon ausgehen, daß beim erfolgreichen Einbuchen eines IDoc-Beleges im Empfängersystem, d.h. wenn keine Fehlermeldung auftritt, der SHBV-Beleg tatsächlich vollständig und richtig verbucht wurde.
So könnte es möglich sein, daß beispielsweise reine FI-Anzahlungen erfolgreich verarbeitet werden können. Anzahlungen mit Zusatzkontierungen, z.B. auf Bestellungen, Anlagen, Aufträge, werden nicht vollständig verbucht.
Bei Bestellungen wird die Bestellhistorie nicht fortgeschrieben. Die Bestellungen werden sofort ausgeglichen, es ist keine Verrechnung möglich.
Bei Anlagen werden keine zusätzlichen Verrechnungszeilen erzeugt.
Bei Aufträgen wird kein Anzahlungs-Obligo fortgeschrieben.
Sollte der Anwender trotzdem SHBV aus dem dezentralen System versenden wollen, sind entsprechende Tests des Anwenders unerläßlich!

Anzahlungsanforderungen können im SAP-Standard nicht per ALE versendet werden.
Es ist wegen der Vielzahl der Möglichkeiten, wie ein Anwender ALE FI verwendet, auch nicht geplant (,weil nicht möglich), dafür eine Standardlösung zu entwickeln.
Allerdings ist es im Rahmen einer Kunden-Projektlösung möglich und wurde auch bereits realisiert, entsprechend der speziellen Konstellation beim Anwender, ein Verteilen von Anzahlungsanforderungen zu ermöglichen (-> SAP Beratung).
 

Genau so eine "Kunden-Projektlösung" zu finden, wie im oben rot markierten Abschnitt erwähnt, war gerade meine Aufgabe in meinem aktuellen Kundenprojekt. Es ist hierbei ein zwei System-Szenario gegeben, d.h. ein bestehendes ECC Logistiksystem soll an ein neues S/4-FI/CO System angebunden werden. Wegen der hohen Lizenzkosten und der begrenzten Lebensdauer dieses Szenarios (das Logistiksystem soll im zweiten Schritt ebenfalls in das S/4-System einziehen) wurde der von der SAP favorisierte Central Finance (CFIN) Ansatz verworfen und stattdessen auf ALE-Verteilung gesetzt. Dabei wurden die bekannten Restriktionen, was u.a. SHB-Vorgänge angeht, evaluiert und in Kauf genommen.

Was jedoch (kreditorische) Anzahlungsanforderungen angeht, musste ein Workaround her, da diese Vorgänge zum Teil vom Rechnungsworkflow-System, welches wiederum an das ECC Logistiksystem angebunden ist, ausgelöst werden. D.h., wir mussten einen Weg finden, die Anzahlungsanforderungen am "Türsteher" vorbeizukriegen, damit diese Merkposten vom ECC ans S/4-System verteilt werden, weil dort logischerweise der Zahllauf stattfindet.

 Die Schwierigkeit bei einem komplexen System wie SAP ist, erstmal die Tür zu finden, um im Endeffekt den Türsteher zu lokalisieren. Damit Euch die Suche erspart bleibt, hier die (mir bekannten) Türsteher:

1. Funktionsbaustein FI_IDOC_UPDATE, Zl. 96ff.:

  IF NOT T_BKPF-BSTAT IS INITIAL.
      CHECK X_GLFLEX_ACTIVE = 'X' AND "NewGL ist aktiv
            T_BKPF-BSTAT    = 'L'.    "Buchung in nicht führendes Ledger
  ENDIF.

Bei Belegen mit Belegstatus ungleich leer, werden hier nur solche durchgelassen, die den Belegstatus L (Ledgerspezifische Buchung bei aktivem NewGL) tragen. D.h., Merkposten mit Belegstatus S, wozu ja auch die Anzahlungsanforderungen gehören, haben hier keine Chance. 

Um die Tür auch für Merkposten aufzumachen, muss diese Stelle geeignet modifiziert werden, z.B. so:  

IF NOT T_BKPF-BSTAT IS INITIAL.    
   if not ( t_bkpf-bstat = 'S' and line_exists( t_bseg[ umsks = 'A' ] ) ). "<<<<INSERT
   CHECK X_GLFLEX_ACTIVE = 'X' AND "NewGL ist aktiv
            T_BKPF-BSTAT    = 'L'.    "Buchung in nicht führendes Ledger
   ENDIF.     "<<<<INSERT                                                             
 ENDIF.

2. Funktionsbaustein FI_IDOC_PREPARE, Zl. 260ff.:

* Belegstatus prüfen (keine Muster-, Dauerbuchungsurbelege versenden)
    IF NOT t_bkpf-bstat IS INITIAL.
      IF x_send_c3 = 'X'.
        CHECK x_glflex_active = 'X' AND "NewGL ist aktiv
              ( t_bkpf-bstat    = 'L' OR t_bkpf-bstat    = 'S' ).    "Buchung in nicht führendes Ledger + Anzahlungsanf.
      ELSE.
        CHECK x_glflex_active = 'X' AND "NewGL ist aktiv
              t_bkpf-bstat    = 'L'.    "Buchung in nicht führendes Ledger
      ENDIF.
    ENDIF. 

Anzahlungsanforderungen (BKPF-BSTAT = 'S') werden hier nur durchgelassen, wenn NewGL aktiv ist und der NewGL-Nachrichtentyp FAGLDT01 verwendet wird. Um Merkposten auch bei nicht aktivem NewGL und Verwendung der Nachrichtentypen FIDCC1 bzw. FIDCC2 zu verteilen, muss der o.g. Abschnitt entsprechend modifiziert werden z.B. so:

* Belegstatus prüfen (keine Muster-, Dauerbuchungsurbelege versenden)
    IF NOT t_bkpf-bstat IS INITIAL.
    if not ( t_bkpf-bstat = 'S' and line_exists( t_bseg[ umsks = 'A' ] ) ). "<<<<INSERT
      IF x_send_c3 = 'X'.
        CHECK x_glflex_active = 'X' AND "NewGL ist aktiv
              ( t_bkpf-bstat    = 'L' OR t_bkpf-bstat    = 'S' ).    "Buchung in nicht führendes Ledger + Anzahlungsanf.
      ELSE.
        CHECK x_glflex_active = 'X' AND "NewGL ist aktiv
              t_bkpf-bstat    = 'L'.    "Buchung in nicht führendes Ledger
      ENDIF.
    endif.    "<<<<INSERT
    ENDIF. 

Wie im eingangs erwähnten SAP-Hinweis beschrieben, müssen solche Eingriffe in die Verteilungslogik natürlich umfänglich getestet werden. Ich habe allerdings zumindest bei der Verteilung von Anzahlungsanforderungen bisher keine unerwünschten Seiteneffekte feststellen können.

Öfter habe ich in letzter Zeit in einschlägigen Foren Anfragen bezüglich einer Möglichkeit gelesen, bereits gebuchte Belege per ALE in ein anderes System zu replizieren. Ohne weiteres ist dies ja nur für neu gebuchte Belege nach der Einrichtung des entsprechenden ALE-Verteilungsszenarios möglich. SAP ruft hierzu im Standard-Ablauf den Funktionsbaustein FI_IDOC_CREATE_FIDCC2 auf. 

Mithilfe eines kundeneigenen Programms kann dieser bei Bedarf auch verwendet werden, um Belege, die vor Einrichtung des ALE-Szenarios gebucht wurden, in das Ziel-System zu replizieren.

Tatsächlich ist eine 1:1-Verteilung vergleichsweise einfach zu programmieren, siehe nachfolgendes Coding-Beispiel...

*&---------------------------------------------------------------------*
*& Report Y_MIGRATE_OPS
*&---------------------------------------------------------------------*
*& REPLICATE FI DOCUMENTS VIA ALE DISTRIBUTION - SAMPLE PROGRAM
*&---------------------------------------------------------------------*
REPORT y_replicate_fidocs.
DATA: lt_bkpf TYPE TABLE OF bkpf,
      lt_bseg TYPE TABLE OF bseg,
      lt_bset TYPE TABLE OF bset.
DATA: lt_bkpf_sel TYPE TABLE OF bkpf.
DATA: lv_ownsys LIKE tbdls-logsys.
DATA: lv_buk_global TYPE t001-bukrs_glob.
DATA: ls_bkpf TYPE bkpf.
DATA: lv_prot_title TYPE lvc_title.
SELECT-OPTIONS: so_bukrs FOR ls_bkpf-bukrs,
                so_belnr FOR ls_bkpf-belnr,
                so_gjahr FOR ls_bkpf-gjahr.
PARAMETERS:     pa_logsy LIKE tbd03-rcvsystem OBLIGATORY.
PARAMETERS:     pa_xtest AS CHECKBOX DEFAULT 'X'.

START-OF-SELECTION.
  CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
    IMPORTING
      own_logical_system = lv_ownsys.
 

  SELECT * FROM bkpf INTO TABLE lt_bkpf_sel
      WHERE bukrs IN so_bukrs
        AND belnr IN so_belnr
        AND gjahr IN so_gjahr.

  LOOP AT lt_bkpf_sel INTO ls_bkpf.
    CLEAR: lt_bkpf[].
    APPEND ls_bkpf TO lt_bkpf.
    CLEAR: lt_bseg[], lt_bset[].
    SELECT * FROM bseg INTO TABLE lt_bseg
        WHERE belnr = ls_bkpf-belnr
          AND bukrs = ls_bkpf-bukrs
          AND gjahr = ls_bkpf-gjahr.
    SELECT * FROM bset INTO TABLE lt_bset
        WHERE belnr = ls_bkpf-belnr
          AND bukrs = ls_bkpf-bukrs
          AND gjahr = ls_bkpf-gjahr.

    SELECT SINGLE bukrs_glob FROM t001 INTO lv_buk_global
        WHERE bukrs = ls_bkpf-bukrs.

    IF pa_xtest IS INITIAL.

      SET UPDATE TASK LOCAL.
      CALL FUNCTION 'FI_IDOC_CREATE_FIDCC2'
        EXPORTING
          i_sendsys    = lv_ownsys
          i_recsys     = pa_logsy
          i_bukrs_glob = lv_buk_global
        TABLES
          t_bkpf       = lt_bkpf
          t_bseg       = lt_bseg
          t_bset       = lt_bset
        EXCEPTIONS
          error        = 1
          OTHERS       = 2.

      COMMIT WORK AND WAIT.

    ENDIF.

  ENDLOOP.

  IF pa_xtest = abap_true.
    lv_prot_title = 'TEST RUN - List of documents to be replicated - NO IDOCS GENERATED!!!'.
  ELSE.
    lv_prot_title = 'PROD RUN - List of replicated documents - IDOCS WERE GENERATED!!!'.
  ENDIF.

  CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
    EXPORTING
      i_structure_name = 'BKPF'
      i_grid_title     = lv_prot_title
    TABLES
      t_outtab         = lt_bkpf_sel.

Sofern Mappings / Veränderungen einzelner Datenfelder erforderlich sind, müssten diese natürlich noch in das o.g. Coding integriert werden.

Öfters kam in Kundenprojekten die Anforderung hoch, Informationen aus dem Kontierungshandbuch dem Belegerfasser während des Buchungsvorganges zugänglich zu machen. Eins vorweg: eine 1A-Lösung, die unabhängig vom verwendeten User-Interface funktioniert, habe ich bisher noch nicht gefunden, aber immerhin eine, die modifikationsfrei eingebaut werden kann und zumindest mal bei den gängigen GUI-Transaktionen (FB01, FB50, FB60 etc.) funktioniert. Sie fusst auf dem Business Transaction Event-Framework (BTE) und setzt voraus, dass die Informationen zum Kontierungshandbuch in Form von Standardtexten am Sachkontenstamm vorliegen. Für die Implementierung sind zumindest Grundkenntnisse in der ABAP-Programmierung vonnöten.

Textablage

Im SAP-Standard ist für die Ablage der Kontierungsinformationen zu einem Konto, die Text-ID 0001 (Kontierungsinfo) des Textobjektes SKB1 (Sachkontentexte im Buchungskr.) vorgesehen. Der technische Name des jeweiligen Textbausteins setzt sich aus der 10-stelligen Kontonummer (ggf. mit führenden Nullen) und dem Schlüssel des Buchungskreises (4-stellig) zusammen (Beispiel: Konto 4711, Buchungskreis 0001: 00000047110001). Diese Texte können in der Buchungskreissicht des Sachkontos mithilfe der Sachkontenpflege FS00 hinterlegt werden.

Um sich die so gepflegten Kontierungsinformationen anzeigen zu lassen, kann der Standardreport "Kontierungshandbuch" ausgeführt werden. Der Bericht ist im Infosystem des Hauptbuchs, Bereich "Stammdaten" zu finden (Transaktion S_ALR_87012330 - Kontierungshandbuch).

Unter S/4 wurde diese Transaktion als obsolet gekennzeichnet und ist nicht mehr aufrufbar. Um dies bei Bedarf dennoch zu ermöglichen, bitte gemäß Hinweis 2393666 vorgehen.

Um die Pflege der Kontierungsinformationen zu vereinfachen, habe ich mal in einem Kundenprojekt ein kleines Uploadprogramm geschrieben, welches eine entsprechend aufbereitete Excel-Vorlage hochladen kann.

Excel-Vorlage:

Wenn in der Vorlage buchungskreisspezifische Texte hinterlegt werden sollen, ist der Buchungskreis in der entsprechenden Spalte anzugeben. Ist der Wert in der Spalte "Buchungskreis" leer, wird der Text in allen Buchungskreisen, in denen das Konto vorhanden ist und die den angegebenen Kontenplan verwenden, aktualisiert.

Die Felder Kontenplan, Konto, Sprache und Text sind obligatorisch. Führende Nullen bei der Angabe des Kontos können weggelassen werden. Das Programm füllt dies automatisch auf. Der Buchungskreis ist ggf. mit führenden Nullen einzugeben.

Bei der Ausführung des Upload-Programms ist lediglich die Excel-Datei auszuwählen (sie kann ohne vorherige Umformatierung direkt im XLSX-Format verwendet werden) und ggf. anzukreuzen, ob bereits manuell gepflegte Texte bei diesem Lauf überschrieben werden sollen. 

Coding:

REPORT ystxupl1.
*&---------------------------------------------------------------------*
*& Report YSTXUPL1
*&---------------------------------------------------------------------*
*& Upload SAPScript-Texts for accounting manual from Excel
*&---------------------------------------------------------------------*

DATA: data_tab TYPE TABLE OF string.

TYPES: BEGIN OF ty_txt,
         ktopl    TYPE t001-ktopl,
         bukrs    TYPE t001-bukrs,
         spras(2) TYPE c,
         saknr    TYPE skb1-saknr,
         txt      TYPE string,
       END OF ty_txt.

TYPES: tty_bukrs TYPE TABLE OF bukrs,
       tty_t001  TYPE TABLE OF t001.

DATA:  wa_txt TYPE ty_txt.
DATA:  it_txt TYPE TABLE OF ty_txt.

*&---------------------------------------------------------------------*
*& SELECTION-SCREEN
*&---------------------------------------------------------------------*
PARAMETERS: pa_fnam LIKE rlgrap-filename OBLIGATORY. "Excelfilename
PARAMETERS: pa_xovr AS CHECKBOX DEFAULT space.       "Overwrite y/n

*&---------------------------------------------------------------------*
AT SELECTION-SCREEN ON VALUE-REQUEST FOR pa_fnam.
*&---------------------------------------------------------------------*
  PERFORM f4_filename.

START-OF-SELECTION.
  PERFORM upload_data.
  PERFORM save_texts.

*&---------------------------------------------------------------------*
*& Form UPLOAD_DATA
*&---------------------------------------------------------------------*
*& upload accounting manual template (Excel)
*&---------------------------------------------------------------------*
FORM upload_data .

  DATA: l_buf   TYPE string,
        l_tabix TYPE sy-tabix.

  CLEAR data_tab[].

  CALL FUNCTION 'FAA_FILE_UPLOAD_EXCEL'
    EXPORTING
      i_filename           = pa_fnam
      i_delimiter          = '~'
    TABLES
      et_filecontent       = data_tab
    EXCEPTIONS
      error_accessing_file = 1
      OTHERS               = 2.

  IF sy-subrc <> 0.
    WRITE: / 'Fehler', sy-subrc, 'beim Upload der Datei', pa_fnam.
  ENDIF.

  LOOP AT data_tab INTO l_buf.
    CHECK sy-tabix > 1.  "Skip Header
    SPLIT l_buf AT '~' INTO
         wa_txt-ktopl
         wa_txt-bukrs
         wa_txt-spras
         wa_txt-saknr
         wa_txt-txt.

*   clean up multiple text lines.
    IF wa_txt-txt(1) = '"'.
      SHIFT wa_txt-txt BY 1 PLACES LEFT.
    ENDIF.
    DATA(l_lastchar) = strlen( wa_txt-txt ) - 1.
    IF wa_txt-txt+l_lastchar(1) = '"'.
      wa_txt-txt = wa_txt-txt(l_lastchar).
    ENDIF.

    APPEND wa_txt TO it_txt.
  ENDLOOP.

ENDFORM.

*&---------------------------------------------------------------------*
*& Form F4_FILENAME
*&---------------------------------------------------------------------*
*& F4 help Excel-file
*&---------------------------------------------------------------------*
FORM f4_filename .

  CALL FUNCTION 'FAA_FILE_F4'
    EXPORTING
      i_default_extension = 'XLS'
    IMPORTING
      e_filename          = pa_fnam
    EXCEPTIONS
      interface_error     = 1
      OTHERS              = 2.
  IF sy-subrc <> 0.
    MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
            WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
  ENDIF.

ENDFORM.
*&---------------------------------------------------------------------*
*& Form save_texts
*&---------------------------------------------------------------------*
*& Process accounting manual texts and save them
*&---------------------------------------------------------------------*
FORM save_texts .

  DATA: lt_lines TYPE TABLE OF tline,
        l_name   TYPE thead-tdname,
        l_saknr  TYPE skb1-saknr,
        lt_t001  TYPE tty_t001,
        l_spras  TYPE t001-spras,
        lt_bukrs TYPE tty_bukrs.

  LOOP AT it_txt INTO wa_txt.

*   convert external data into SAP format, if necessary
    CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'
      EXPORTING
        input  = wa_txt-saknr
      IMPORTING
        output = wa_txt-saknr.
    CALL FUNCTION 'CONVERSION_EXIT_ALPHA_OUTPUT'
      EXPORTING
        input  = wa_txt-spras
      IMPORTING
        output = l_spras.

*   select company codes assigned to chart of acc.
*   in case company code isn't specified in excel template
    IF lt_t001[] IS INITIAL.
      SELECT * FROM t001 INTO TABLE lt_t001 WHERE ktopl = wa_txt-ktopl.
    ENDIF.

    IF wa_txt-bukrs IS INITIAL.
      PERFORM find_company_codes USING    wa_txt-ktopl
                                          wa_txt-saknr
                                          lt_t001
                                 CHANGING lt_bukrs.
    ELSE.
      CLEAR lt_bukrs[].
      APPEND wa_txt-bukrs TO lt_bukrs.
    ENDIF.

    LOOP AT lt_bukrs INTO wa_txt-bukrs.

      CONCATENATE wa_txt-saknr wa_txt-bukrs INTO l_name.

      IF pa_xovr IS INITIAL.
        CALL FUNCTION 'READ_TEXT'
          EXPORTING
            id                      = '0001'
            language                = l_spras
            name                    = l_name
            object                  = 'SKB1'
          TABLES
            lines                   = lt_lines
          EXCEPTIONS
            id                      = 1
            language                = 2
            name                    = 3
            not_found               = 4
            object                  = 5
            reference_check         = 6
            wrong_access_to_archive = 7
            OTHERS                  = 8.
        IF sy-subrc <> 0.
          PERFORM store_text USING l_spras l_name wa_txt.
        ENDIF.
      ELSE.
        PERFORM store_text USING l_spras l_name wa_txt.
      ENDIF.

    ENDLOOP.

  ENDLOOP.

ENDFORM.

*&---------------------------------------------------------------------*
*& Form find_company_codes
*&---------------------------------------------------------------------*
*& Select all company codes with given chart of accounts
*&---------------------------------------------------------------------*
*&      --> pi_KTOPL
*&      --> pi_SAKNR
*&      --> pt_t001
*&      <-- pt_BUKRS
*&---------------------------------------------------------------------*
FORM find_company_codes  USING    pi_ktopl TYPE t001-ktopl
                                  pi_saknr TYPE skb1-saknr
                                  pt_t001  TYPE tty_t001
                         CHANGING pt_bukrs TYPE tty_bukrs.

  CLEAR pt_bukrs[].
  LOOP AT pt_t001 ASSIGNING FIELD-SYMBOL(<lfs_t001>).
    SELECT SINGLE COUNT(*) FROM skb1
           WHERE saknr = pi_saknr
             AND bukrs = <lfs_t001>-bukrs.
    IF sy-subrc = 0.
      APPEND <lfs_t001>-bukrs TO pt_bukrs.
    ENDIF.
  ENDLOOP.

ENDFORM.
*&---------------------------------------------------------------------*
*& Form store_text
*&---------------------------------------------------------------------*
*& Put SAPScript-Tests for accouting mmanual in DB
*&---------------------------------------------------------------------*
*&      --> pi_SPRAS  Language
*&      --> pi_NAME   Textname
*&      --> pi_TXT    Text
*&---------------------------------------------------------------------*
FORM store_text  USING    pi_spras TYPE t001-spras
                          pi_name  TYPE thead-tdname
                          pi_txt   LIKE wa_txt.

  DATA: lt_tline TYPE tline_t.
  DATA: ls_header TYPE thead.

  DATA(lt_strings) = VALUE string_table( ( pi_txt-txt ) ).

* Stringtabelle -> TLINE-Tabelle
* SAPscript: Konvertieung Textstream nach ITF f¸r TextEditControl
  CALL FUNCTION 'CONVERT_STREAM_TO_ITF_TEXT'
    EXPORTING
      stream_lines = lt_strings
      lf           = abap_true
    TABLES
      itf_text     = lt_tline.

  ls_header-tdobject = 'SKB1'.
  ls_header-tdname   = pi_name.
  ls_header-tdspras  = pi_spras.
  ls_header-tdid     = '0001'.
  CALL FUNCTION 'SAVE_TEXT'
    EXPORTING
      header          = ls_header
      savemode_direct = 'X'
    TABLES
      lines           = lt_tline.

ENDFORM.

Interaktive Anzeige der Kontierungsinformationen

Um nun die so gepflegten Texte während des Buchens zur Anzeige zu bringen, implementieren wir die Business Transaction Events (BTE) 00001070 bzw. 00001080 (P/S-Schnittstelle). Details zur Implementierung von BTEs finden sich u.a. hier.

Mustercoding zur Implementierung der BTE-Bausteine:

BTE 00001070

FUNCTION y_interface_00001070.
*"--------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"  IMPORTING
*"     REFERENCE(I_BKPF) TYPE  BKPF
*"     REFERENCE(I_BSEG) TYPE  BSEG
*"     REFERENCE(I_AKTYP) TYPE  AKTYP
*"     REFERENCE(I_DYNCL) TYPE  DYNCL
*"  EXPORTING
*"     REFERENCE(E_XCHNG) LIKE  OFIWA-XCHNG
*"--------------------------------------------------------------------
  DATA: lv_tdname   TYPE stxh-tdname,
       lv_tdobject TYPE stxh-tdobject VALUE 'SKB1',
       lv_tdid     TYPE stxh-tdid VALUE '0001'.

  CONCATENATE i_bseg-hkont i_bkpf-bukrs INTO lv_tdname.

  CALL FUNCTION 'RECA_GUI_TEXTEDIT_POPUP'
    EXPORTING
      id_tdobject = lv_tdobject
      id_tdname   = lv_tdname
      id_tdid     = lv_tdid
      id_activity = '03'
      id_title    = TEXT-002.

ENDFUNCTION.

TEXT-002 enthält dabei die Überschrift der Dialogbox, in der die Kontierungsinformation angezeigt wird.

BTE 00001080

FUNCTION y_interface_00001080.
*"--------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"  IMPORTING
*"     REFERENCE(I_SPRAS) LIKE  SY-LANGU
*"     REFERENCE(I_AKTYP) TYPE  AKTYP
*"     REFERENCE(I_DYNCL) TYPE  DYNCL
*"  EXPORTING
*"     VALUE(E_FTEXT) LIKE  FTEXTS-FTEXT
*"--------------------------------------------------------------------

  e_ftext = TEXT-001.

ENDFUNCTION.

TEXT-001 enthält dabei die Aufschrift der Drucktaste, die in den Buchungstransaktionen zusätzlich eingeblendet wird, also z.B. "Kontierungshandbuch".

Im Ergebnis erscheint im Detailbild der Belegerfassung (z.B.in der FB01 oder bei der FB60, wenn ein Doppelklick auf die zu erfassende Belegzeile erfolgt) eine neue Drucktaste. Beim Betätigen der Drucktaste wird die zum aktuellen Konto/Buchungskreis hinterlegte Kontierungsinformation in einer Dialogbox angezeigt.

Der Pivot-Browser (PIVB) ist ein neues Ausgabe-Framework der SAP, welches die Anzeige beliebiger (strukturierter) Dateninhalte in Tabellenform ermöglicht. Die Art der Darstellung der Daten ist dabei an das bekannte ALV-Grid angelehnt. Im Unterschied zum ALV geht der Funktionsumfang des Pivot-Browsers jedoch über die reine Aufbereitung und Anzeige der Daten hinaus. Auch die Datenbeschaffung (HANA-optimiert) sowie die Behandlung von Benutzerinteraktionen ist in das Framework integriert. 

Details hierzu finden sich in den PDF-Anhängen zum Hinweis 2100879 - Pivot Browser: Dokumentation

Einige der im Standard ausgelieferten Funktionalitäten, die auf dem Pivot-Browser basieren, sind die Einzelpostenbrowser in der S/4 Finanzbuchhaltung:

Während der Anzeige-Bereich (links) weitestgehend identisch zum bekannten ALV funktioniert, ist der Interaktionsbereich (rechts) ein neu gestaltetes Element im Pivot-Browser. 

Im Bereich Spalten können die anzuzeigenden Felder ausgewählt werden. Bei den o.g. FI-Einzelpostenbrowsern stehen gegen Ende der Liste auch Stammdatenfelder und Bezeichnungen zur Verfügung. So kann bspw. zur Kostenstelle die entsprechende Kostenstellenbezeichnung in die Anzeige geholt werden, ohne wie bei den klassischen Einzelpostenlisten (FBLxN) den Feldvorrat erweitern und die Inhalte per BTE/BADI nachlesen zu müssen.

Der Bereich Layouts enthält alle verfügbaren Anzeigelayouts und ermöglicht deren Verwaltung wie unter ALV bekannt (entsprechende Berechtigung vorausgesetzt).

Interessant ist der Bereich Aktionen, in dem für den aktuellen Anzeigevorrat verfügbare Benutzeraktionen dargestellt sind. Diese können in einer (max. zweistufigen) Baumstruktur angeordnet werden, um so gewisse Interaktionen zu gruppieren. 

Sie ahnen es wahrscheinlich schon, dieser Bereich lässt sich modifikationsfrei beliebig erweitern und mit kundenspezifischen Aktionen spicken...

Weiter unten möchte ich ein Beispiel für eine solche kundeneigene Aktion zeigen, das die Erzeugung von Abgrenzungsobjekten der Accrual Engine bzw. des Accruals Management (ab S/4 1809) direkt aus den Einzelpostenbrowsern der Finanzbuchhaltung ermöglicht.

Die einzelnen Anwendungen des Pivot-Browsers werden als Erweiterungsimplementierung des Erweiterungsspots PIVB registriert. Für die EP-Browser im FI (s.o.) ist dies die Implementierung FAGL_LIB_PIVB. In ihr wiederum werden die Implementierungen zur BadI-Definition FAGL_LIB gerufen, zu der auch kundeneigene Implementierungen angelegt werden können.

Für die Aktionen sind die beiden Interface-Methoden SIDEBAR_ACTIONS_SET und SIDEBAR_ACTIONS_HANDLE relevant. In ersterer kann der "Aktionsbaum" um kundeneigene Aktionen erweitert werden, in der zweitgenannten Methode wird dann die eigentliche Aktion ausgestaltet.

Fügen wir also zunächst eine Aktion in einem kundeneigenen Ordner hinzu:

METHOD if_fagl_lib~sidebar_actions_set.

*   Kundeneigene Aktionen im Einzelpostenbrowser 

    TYPE-POOLS: icon.

*   Neuer Ordner am Ende anfügen
    APPEND INITIAL LINE TO c_menu-t_folder_level1 ASSIGNING FIELD-SYMBOL(<lf_folder>).
    <lf_folder>-folder_key = 'ZZACE'.
    <lf_folder>-folder_text = 'Abgrenzungsobjekt'.

*   Aktion in den neuen Ordner einfügen
    APPEND INITIAL LINE TO <lf_folder>-t_item_level2 ASSIGNING FIELD-SYMBOL(<lf_menuitem>).
    <lf_menuitem>-item_key = 'ZZACE_CREATE'.
    <lf_menuitem>-text = 'Abgrenzungsobjekt anlegen'.
    <lf_menuitem>-icon = icon_fencing.

  ENDMETHOD.

...und nun kann die Aktion, die mit der ID ZZACE_CREATE angelegt wurde, ausgestaltet werden.

  METHOD if_fagl_lib~sidebar_actions_handle.

*   Kundeneigene Aktionen im Einzelpostenbrowser 

    DATA: l_checker TYPE i.
    DATA: ls_bseg TYPE bseg.
    DATA: ls_bkpf TYPE bkpf.

    l_checker = 0.

    CASE i_navigate_item_key.
      WHEN 'ZZACE_CREATE'.   "Abgrenzungsobjekt anlegen
        IF it_outtab_selected_rows[] IS NOT INITIAL.                                            "Mind. eine Zeile selektiert?
          LOOP AT it_column ASSIGNING FIELD-SYMBOL(<lf_col>) WHERE fieldname = 'BUKRS' OR       "Felder Bukrs, Belnr, Gjahr und Buzei in Liste?
                                                                   fieldname = 'BELNR' OR
                                                                   fieldname = 'GJAHR' OR
                                                                   fieldname = 'BUZEI'.
            IF <lf_col>-is_invisible = abap_false.
              ADD 1 TO l_checker.
            ENDIF.
          ENDLOOP.
          IF l_checker < 4.
            MESSAGE 'Bitte mind. BUKRS BELNR GJAHR BUZEI in Anzeige holen' TYPE 'I'.
            EXIT.
          ELSE.
            "Belegdaten nachlesen
            READ TABLE it_outtab INDEX it_outtab_selected_rows[ 1 ]-row_id ASSIGNING FIELD-SYMBOL(<lf_row>).
            MOVE-CORRESPONDING <lf_row> TO ls_bseg.
            SELECT SINGLE * FROM bkpf INTO ls_bkpf
                    WHERE bukrs = ls_bseg-bukrs
                      AND belnr = ls_bseg-belnr
                      AND gjahr = ls_bseg-gjahr.
            SELECT SINGLE * FROM bseg INTO ls_bseg
                    WHERE bukrs = ls_bkpf-bukrs
                      AND belnr = ls_bkpf-belnr
                      AND gjahr = ls_bkpf-gjahr
                      AND buzei = ls_bseg-buzei.
            IF sy-subrc = 0.
              "Aufruf Generierungsprogramm f. Abgrenzungsobjekte
              ls_bseg-dmbtr = abs( ls_bseg-dmbtr ).         "Abgrenzungsbetrag muss positiv sein
              IF ls_bseg-koart NE 'S'.                      "Kontokorrente (FBL1H)
                SUBMIT zacac_d_trans_s4 AND RETURN VIA SELECTION-SCREEN
                       WITH p_check  = 'X'
                       WITH p_efdate = sy-datum
                       WITH p_powip = 'X'
                       WITH so_acmth = 'LINEAR'
                       WITH so_acpst = ls_bkpf-budat
                       WITH so_belnr = ls_bkpf-belnr
                       WITH so_bukrs = ls_bkpf-bukrs
                       WITH so_gjahr = ls_bkpf-gjahr
                       WITH p_amnt   = ls_bseg-dmbtr
                       WITH p_text   = ls_bseg-sgtxt.
              ELSE.                                          "FAGLL03H, FBL3H
                SUBMIT zacac_d_trans_s4 AND RETURN VIA SELECTION-SCREEN
                        WITH p_check  = 'X'
                        WITH p_efdate = sy-datum
                        WITH p_powoip = 'X'                  "Bei Sachkontenposten - OHNE Eröffnungbuchung als Default
                        WITH p_powip  = space
                        WITH so_acmth = 'LINEAR'
                        WITH so_acpst = ls_bkpf-budat
                        WITH so_belnr = ls_bkpf-belnr
                        WITH so_bukrs = ls_bkpf-bukrs
                        WITH so_buzei = ls_bseg-buzei
                        WITH so_gjahr = ls_bkpf-gjahr
                        WITH p_amnt   = ls_bseg-dmbtr
                        WITH p_text   = ls_bseg-sgtxt.
              ENDIF.
            ENDIF.
          ENDIF.
        ENDIF.
    ENDCASE.
  ENDMETHOD.

Da der Pivot-Browser HANA optimiert ist, werden nur die Spalten gelesen, die auch im aktuellen Layout benötigt werden. Dies ist ein wesentlicher Unterschied zu den klassischen EP-Listen, die immer alle Spalten eines Postens lesen, unabhängig von deren Verwendung in der Anzeige.

D.h., es muss zunächst geprüft werden, ob die für die weitere Verarbeitung benötigten Felder auch zur Verfügung stehen!

Im weiteren Verlauf dieses Beispiels wird eine angepasste Z-Kopie des Demo-Reports ACAC_D_TRANS_EXAMPLE_S4 gerufen, der aus einem vorgegebenen Belegvorrat Abgrenzungsobjekte im Accruals Management generiert. Für die "alte" Accrual Engine (vor S/4 1809) wäre dies der Report ACAC_DATA_TRANSFER_EXAMPLE.

Was sich anhört wie der Titel meines gefloppten Rap-Albums, ist in Wahrheit ein Upgrade des beliebten CO-Superhelden BATCHMAN, mit dem CO-Belege aus externen Dateien ins System geladen werden können. Mein Kollege Markus Läller hat hierzu den von SAP ausgelieferten schwachbrüstigen Schummeldiesel rausgerissen und durch ein bärenstarkes 5.0-Liter V8-Aggregat ersetzt.

Im Vergleich zur Standardauslieferung hat der aufgepumpte Batchman folgendes zu bieten:

• Natives Excel-Format kann ohne vorherige Konvertierung ins CSV-Format verwendet werden
• Vorlagen auf das Wesentliche reduziert und übersichtlich
• Keine führenden Nullen in der Uploaddatei für Stammdaten benötigt
• Zahlenformate mit Dezimalpunkt oder -komma unterstützt
• Kostenrechnungskreis wird auf Defaultwert gesetzt, sofern nicht gefüllt
• User wird automatisch gesetzt (SY-UNAME)
• Automatischer Belegsplit, wenn maximal zulässige Zeilenanzahl überschritten wird

Der Download-Link zu den im folgenden beschriebenen,  vereinfachten Excel-Vorlagen findet sich weiter hinten in diesem Artikel.

Wer den BATCHMAN noch gar nicht kennt, kann sich hier mit der Standardauslieferung vertraut machen.

Unterstützte Datenübernahmen

Manuelle Kostenverrechnung

Mit Hilfe der manuellen Kostenverrechnung können Kosten umgebucht werden. Dabei wird ein Senderobjekt (z.B. eine Kostenstelle) entlastet und ein Empfängerobjekt (z.B. eine andere Kostenstelle/ein Auftrag) belastet. Dies ist als Ergänzung der maschinellen Verfahren für die Kostenverrechnung (Umlage, Verteilung) zu verstehen, bei denen nicht mit festen Regeln gearbeitet werden kann.
Im SAP Standard wird die manuelle Kostenverrechnung mit der Transaktion KB15N durchgeführt. Mittels der Transaktion BATCHMAN können Massendaten unter Zuhilfenahme folgender Vorlage gebucht werden:

Die Vorlage besitzt folgenden Aufbau:

Allgemein
Die Spalte A darf nicht verändert werden. Hier stehen die Strukturdaten, die dynamisch die Zeileninformationen aufbauen. Neben den Strukturen stehen die Felder, die in den Strukturen enthalten sind .
Die Daten werden ab Zeile 4 übernommen, d.h. die Zeile 3 (leer) darf nicht gelöscht werden.
Es dürfen maximal 9999 Zeilen angegeben werden (inklusive Leerzeilen).

Belegkopf
Das Feld DOC_NO stellt die Verbindung zwischen Belegkopf und Belegposition her. Somit es möglich, 1 bis n Belege zu erzeugen.
Im Feld DOC_HDR_TX kann ein Belegkopftext angegeben werden.
In den Feldern Belegdatum und Buchungsdatum können Angaben gemacht werden. Bleiben die Felder leer, wird das Systemdatum (=Tagesdatum) übernommen.
Im Feld TRANS_CURR muss die Transaktionswährung angegeben werden.

Belegposition
Das Feld DOC_NO stellt die Verbindung zwischen Belegkopf und Belegposition her. Somit es es möglich, 1 bis n Belege zu erzeugen.
Im Feld COST_ELEM ist die umzubuchende Kostenart anzugeben. Die Kostenart darf ohne führende Nullen angegeben werden.
Im Feld VALUE_TCUR  muss der Wert der Buchung angegeben werden. Dezimalstellen können mit Punkt oder Komma angegeben werden.
Im Feld SEND_CCTR ist die abgebende SAP Kostenstelle anzugeben. Die Kostenstelle darf ohne führende Nullen angegeben werden.
Im Feld REC_CCTR ist die empfangende SAP Kostenstelle anzugeben, sofern kein echter Auftrag kontiert werden soll. Die Kostenstelle darf ohne führende Nullen angegeben werden.
Sofern ein Auftrag kontiert werden soll, ist das Feld REC_ORDER mit der SAP Auftragsnummer zu füllen. Die Auftragsnummer darf ohne führende Nullen angegeben werden.
Im Feld SEG_TEXT kann ein Positionstext angegeben werden.
 

Manuelle Umbuchung Kosten

Mittels der Funktion manuelle Umbuchung Kosten können Primärkosten umgebucht werden. Die Originalkostenart bleibt immer erhalten. Die Funktion wurde vorwiegend konzipiert, um Fehlbuchungen zu korrigieren. Es ist im Einzelfall zu entscheiden, ob wirklich im CO umgebucht werden sollte oder doch lieber die Buchung im Finanzwesen zu korrigieren ist.
Wichtig: Anders als bei der manuellen Kostenverrechnung wird das abgebende Objekt (z.B. die Kostenstelle) nicht mit Entlastungskennzeichen gebucht, sondern mit negativem Belastungskennzeichen.
Im SAP Standard wird die manuelle Umbuchung der Kosten mit der Transaktion KB11N durchgeführt. 

Die Vorlage besitzt folgenden Aufbau:

Allgemein
Die Spalte A darf nicht verändert werden. Hier stehen die Strukturdaten, die dynamisch die Zeileninformationen aufbauen. Neben den Strukturen stehen die Felder, die in den Strukturen enthalten sind .
Die Daten werden ab Zeile 4 übernommen, d.h. die Zeile 3 (leer) darf nicht gelöscht werden.
Es dürfen maximal 9999 Zeilen angegeben werden (inklusive Leerzeilen).

Belegkopf
Das Feld DOC_NO stellt die Verbindung zwischen Belegkopf und Belegposition her. Somit es möglich, 1 bis n Belege zu erzeugen.
Im Feld DOC_HDR_TX kann ein Belegkopftext angegeben werden.
In den Feldern Belegdatum und Buchungsdatum können Angaben gemacht werden. Bleiben die Felder leer, wird das Systemdatum (=Tagesdatum) übernommen.
Im Feld TRANS_CURR muss die Transaktionswährung angegeben werden.

Belegposition
Das Feld DOC_NO stellt die Verbindung zwischen Belegkopf und Belegposition her. Somit es es möglich, 1 bis n Belege zu erzeugen.
Im Feld COST_ELEM ist die umzubuchende Kostenart anzugeben. Die Kostenart darf ohne führende Nullen angegeben werden.
Im Feld VALUE_TCUR  muss der Wert der Buchung angegeben werden. Dezimalstellen können mit Punkt oder Komma angegeben werden.
Im Feld SEND_CCTR ist die abgebende SAP Kostenstelle anzugeben. Die Kostenstelle darf ohne führende Nullen angegeben werden.
Im Feld REC_CCTR ist die empfangende SAP Kostenstelle anzugeben, sofern kein echter Auftrag kontiert werden soll. Die Kostenstelle darf ohne führende Nullen angegeben werden.
Sofern ein Auftrag kontiert werden soll, ist das Feld REC_ORDER mit der SAP Auftragsnummer zu füllen. Die Auftragsnummer darf ohne führende Nullen angegeben werden.
Im Feld SEG_TEXT kann ein Positionstext angegeben werden.
 

Interne Leistungsverrechnung

Bei der direkten Leistungsverrechnung wird die erbrachte betriebliche Leistung gemessen, erfasst und verrechnet. Hierfür müssen im System die entsprechenden (messbaren) Bezugsgrößen (= Maßgrößen für die Kostenverursachung) angelegt sein. In der Kostenstellenrechnung werden sie als Leistungsarten bezeichnet. Eine Leistungsverrechnung erfolgt beispielsweise durch das Rückmelden von Arbeitsvorgängen bzw. durch Kontieren der Leistung. Hierbei wird die erbrachte Leistung mit dem Tarif der Leistungsart multipliziert.
Dies erfordert auf den entsprechenden Kostenstellen eine Planung der Leistungsarten mit manuell zu setzendem Tarif.
Im SAP Standard wird die Leistungsverrechnung mit der Transaktion KB21N durchgeführt. Mittels der Transaktion BATCHMAN können Massendaten unter zur Hilfenahme folgender Vorlage gebucht werden:
 

Allgemein
Die Spalte A darf nicht verändert werden. Hier stehen die Strukturdaten, die dynamisch die Zeileninformationen aufbauen. Neben den Strukturen stehen die Felder, die in den Strukturen enthalten sind .
Die Daten werden ab Zeile 4 übernommen, d.h. die Zeile 3 (leer) darf nicht gelöscht werden.
Es dürfen maximal 9999 Zeilen angegeben werden (inklusive Leerzeilen).

Belegkopf
Im Feld DOC_HDR_TX kann ein Belegkopftext angegeben werden.
In den Feldern Belegdatum und Buchungsdatum können Angaben gemacht werden. Bleiben die Felder leer, wird das Systemdatum (=Tagesdatum) übernommen.

Belegposition
Im Feld ACTTYPE ist Leistungsart anzugeben. Die Leistungsart darf ohne führende Nullen angegeben werden.
Im Feld ACTVTY_QTY muss die geleistete Menge angegeben werden. Die Leistungseinheit wird aus dem Leistungsartenstammsatz ermittelt und nicht eingebbar.
Im Feld SEND_CCTR ist die abgebende SAP Kostenstelle anzugeben. Die Kostenstelle darf ohne führende Nullen angegeben werden.
Im Feld REC_CCTR ist die empfangende SAP Kostenstelle anzugeben, sofern kein echter Auftrag kontiert werden soll. Die Kostenstelle darf ohne führende Nullen angegeben werden.
Sofern ein Auftrag kontiert werden soll, ist das Feld REC_ORDER mit der SAP Auftragsnummer zu füllen. Die Auftragsnummer darf ohne führende Nullen angegeben werden.
Im Feld SEG_TEXT kann ein Positionstext angegeben werden.
 

Statistische Kennzahl

Statistische Kennzahlen können für Kennzahlenbildungen im Berichtswesen sowie als Bezugsbasis für periodenbezogene Verrechnungen erfasst werden. Dies erfolgt ebenfalls im Rahmen einer vorgangsbezogenen Verrechnung im Controlling.
Im SAP Standard werden statistische Kennzahlen mit der Transaktion KB31N gebucht. Mittels der Transaktion BATCHMAN können Massendaten unter zur Hilfenahme folgender Vorlage gebucht werden:
 

Allgemein
Die Spalte A darf nicht verändert werden. Hier stehen die Strukturdaten, die dynamisch die Zeileninformationen aufbauen. Neben den Strukturen stehen die Felder, die in den Strukturen enthalten sind .
Die Daten werden ab Zeile 4 übernommen, d.h. die Zeile 3 (leer) darf nicht gelöscht werden.
Es dürfen maximal 9999 Zeilen angegeben werden (inklusive Leerzeilen).

Belegkopf
Im Feld DOC_HDR_TX kann ein Belegkopftext angegeben werden.
In den Feldern Buchungsdatum können Angaben gemacht werden. Sofern das Feld leer ist wird das Tagesdatum übernommen.

Belegposition
Im Feld STATKEYFIG ist die statistische Kennzahl anzugeben. Die Kennzahl darf ohne führende Nullen angegeben werden.
Im Feld STAT_QTY muss der Wert/die Menge angegeben werden. Dezimalstellen können mit Komma und Punkt abgetrennt werden.
Im Feld REC_CCTR ist die empfangende SAP Kostenstelle anzugeben, sofern kein echter Auftrag kontiert werden soll. Die Kostenstelle darf ohne führende Nullen angegeben werden.
Sofern ein Auftrag kontiert werden soll, ist das Feld REC_ORDER mit der SAP Auftragsnummer zu füllen. Die Auftragsnummer darf ohne führende Nullen angegeben werden.
Im Feld SEG_TEXT kann ein Positionstext angegeben werden.
 

Vorlagen

Nachfolgend der Download-Link zu den oben beschriebenen Excel-Templates: 

https://drive.google.com/open?id=1PD1TyrMrV0ncoCvSyceVbgiOrvRi_cDD

Es handelt sich im um ein RAR-Archiv, in dem folgende Excel-Vorlagen enthalten sind:

Installation

Legen Sie in der SE24 die Klasse ZCL_IM_BATCHMAN an und betätigen Sie die Drucktaste "Quelltext-basiert". 

Laden Sie anschließend das Coding der Klasse hier herunter und kopieren Sie es in den Editor ein. Aktivieren Sie die Klasse und verankern Sie diese im Customizing unter 

Controlling - Kostenstellenrechnung - Istbuchungen - Datenübernahme aus Fremdsystemen - BAdI: Übernahme von externen CO-Istdaten implementieren...

Legen Sie eine BADI-Implementierung an und geben Sie als implementierende Klasse ZCL_IM_BATCHMAN vor. 

Anschließend ist die Funktionalität aktiv.

Ausführung / Handhabung

In der Transaktion BATCHMAN stehen folgende Funktionen zur Verfügung:

• Ausführen der Datenübernahme
• Nachbearbeiten der Datenübernahme
• Stornieren der Datenübernahme
• Protokoll zur Datenübernahme anzeigen.
   

• Testen/Buchen : Die Datenübernahme kann im Testmodus und im Echtlauf ( Buchen ) gestartet werden. Im Testlauf werden alle erforderlichen Prüfungen durchgeführt, jedoch noch keine Buchungen vorgenommen.
• Warnungen ignorieren : Ist dieses Kennzeichen gesetzt, werden Belege auch dann gebucht, wenn bei der Belegprüfung Warnmeldungen auftreten. Ist das Kennzeichen nicht gesetzt, verhindert das Auftreten von Warnungen bei der Belegprüfung die Buchung des betreffenden Belegs.
• Das Feld Externe Nummernvergabe bitte nicht nutzen.
• Datenübernahme-Text : Den Datenübernahmen kann ein Text zugeordnet werden, um die Identifikation von Daten zu unterstützen.
   

Dateiname Buchungsdaten : Alle bei den Belegprüfungen auftretenden Nachrichten werden protokolliert. Im Echtlauf wird das Protokoll unter der Datenübernahme-Kennung gespeichert. Es kann später mit dieser Kennung gefunden und angezeigt werden (s.a. Protokoll zur Datenübernahme ). Daten, die nicht erfolgreich übernommen werden konnten, werden in einen Nachbearbeitungsvorrat gestellt. Dieser wird ebenfalls über die Kennung der Datenübernahme identifiziert. Dadurch wird gewährleistet, dass sich die Daten zwischen Einlesen und Nachbearbeitung nicht ändern.

Die externe Datenquelle kann mehrfach für die Datenübernahme verwendet werden kann. Die Reaktion der Anwendung auf die mehrfache Übernahme der gleichen Datenquelle kann über die Nachrichtensteuerung der Nachricht 001 des Arbeitsgebietes K41C eingestellt werden. Vorab eingestellt ist, dass der Hinweis auf eine bereits mit der gleichen Datenquelle durchgeführte Datenübernahme als Info-Meldung gezeigt wird, die übergangen werden kann.

Wurde die Datenübernahme im Testlauf durchgeführt, wird folgendes Protokoll ausgegeben:
 

Mittels Buchen kann die Buchung ausgeführt werden:

Das Ergebnis sind entsprechende Buchungsbelege, die wie folgt angezeigt werden können:
 

Nachbearbeiten der Datenübernahme
Testen/Buchen: Die Nachbearbeitung kann im Testmodus oder im Echtlauf (Buchen) erfolgen.

Möglichkeiten:
·    Manuelle Verarbeitung
·    Halbautomatische Verarbeitung
·    Automatische Verarbeitung

Welche der Optionen am besten für die Nachbearbeitung geeignet ist, hängt von der Art der aufgetretenen Fehler ab.
War zum Beispiel zum Zeitpunkt der Datenübernahme für den gewünschten Vorgang die Buchungsperiode gesperrt, sind in der Regel keine Änderungen an den zu buchenden Daten erforderlich. Der Datenübernahme kann automatisch wiederholt werden, nachdem die Periodensperre aufgehoben wurde.
Ist ein Fehler aufgetreten, der nur durch Korrigieren der übernommenen Daten behoben werden kann, kann dies halbautomatisch oder manuell geschehen. Die halbautomatische Nachbearbeitung ist geeignet, wenn Fehler auf der Ebene des Belegkopfes zu beheben sind (z.B. falsches Buchungsdatum oder falsche Referenz ). Sind einzelne Buchungszeilen falsch, wird es nötig sein, diese einzeln manuell zu korrigieren.
Warnungen Ignorieren: Ist dieses Kennzeichen gesetzt, werden Belege auch dann gebucht, wenn bei der Belegprüfung Warnmeldungen auftreten. Ist das Kennzeichen nicht gesetzt, verhindert das Auftreten von Warnungen bei der Belegprüfung die Buchung des betreffenden Belegs.
Externe Nummernvergabe: Dieses Kennzeichen bitte nicht verwenden.
Datenübernahme-ID: Dieser Parameter bestimmt, welche Datenübernahme nachbearbeitet wird.

Zunächst können die zu bearbeitenden Belege aus dem gesamten Nachbearbeitungsvorrat ausgewählt werden. Es können einzelne Belege, Beleggruppen oder alle Belege zur Nachbearbeitung ausgewählt werden.

Im halbautomatischen Modus können Informationen zum Belegkopf wie Kostenrechnungskreis, Version, Buchungsdatum, usw. korrigiert und die so berichtigten Belege automatisch gebucht werden.

Enthält eine Datenübernahme nur Belege eines Typs, werden nur die dafür relevanten Felder zur Korrektur eingeblendet. Wenn eine Datenübernahme Belege zu verschiedenen Vorgängen enthält (z.B. Leistungsverrechnung und Umbuchung von Primärkosten), werden alle Felder angezeigt, die für mindestens einen der Vorgänge geändert werden dürfen. Die korrigierten Werte werden nur dann in die Belege übernommen, wenn sie für den Vorgang des betreffenden Belegs gültige Eingaben sind. Wird zum Beispiel die Version geändert, wird der Wert nicht in Belege zur Umbuchung von Primärkosten übernommen.

Stornieren der Datenübernahme
Die Anwendung erlaubt es, Datenübernahme-Läufe komplett zu stornieren. Wurden einzelne Belege aus dem Lauf bereits manuell storniert, wird eine entsprechende Fehlermeldung ausgegeben, und es werden nur die noch nicht stornierten Belege zum Übernahmelauf storniert.
Testen/Stornieren : Die Stornierung kann im Testmodus oder im Echtlauf (Stornieren) erfolgen.
Warnungen ignorieren : Ist dieses Kennzeichen gesetzt, werden Belege auch dann gebucht, wenn bei der Belegprüfung Warnmeldungen auftreten. Ist das Kennzeichen nicht gesetzt, verhindert das Auftreten von Warnungen bei der Belegprüfung die Buchung des betreffenden Belegs.
Nachbearbeitungsvorrat löschen : Ist das Kennzeichen gesetzt, werden alle zum Datenübernahme-Lauf gehörenden Einträge im Nachbearbeitungsvorrat gelöscht.
Buchungsdatum für Storno : Der Storno kann mit einem Buchungsdatum versehen werden.
Zu stornierende Datenübernahme : Es werden einzelne Datenübernahmen storniert. Sie wählen hier die Datenübernahme-ID aus.

Protokoll zur Datenübernahme anzeigen.
Zu einer Datenübernahme wird das Protokoll angezeigt. In der Regel ist dies das Protokoll aus den Belegprüfungen bei der Datenübernahme. Falls die Datenübernahme nachbearbeitet worden ist, ist das Protokoll erweitert um die Nachrichten aus der Nachbearbeitung. Eine Stornierung der Datenübernahme wird ebenfalls protokolliert.
 

Umlagen im CO führen insbesondere im Bereich der Konzernumlage immer dann zu Problemen, wenn als Empfängerbezugsbasis die Gesamtkosten einer Kostenstelle herangezogen werden sollen und dazu ggfls. noch eine sehr differenzierte Funktionsbereichsdefinition mit vielen Empfängerkostenstellen vorliegt. Dies führt in Großkonzernen und Retail Gesellschaften mit vielen Filialen und damit einhergehend vielen Empfängerkostenstellen dazu, das bei Aufbau der Sender-/Empfängerbeziehungen eine interne Tabelle aufgebaut wird, die ggfls. die Speichergrenzen übersteigt und zu einem Short Dump führt.
Folgendes Programm sorgt dafür, dass die gebuchten Kostenarten (echte Buchung) auf eine statistische Kennzahl verdichtet werden. 

Der Effekt bei einem Kunden war bspw., dass eine nicht lauffähige Umlage nach 1300 Sekunden durchgebucht wurde.

In diesem Zusammenhang wurde auch eine Meldung bei SAP aufgemacht und es gab diesbezüglich einen regen Austausch mit dem SAP Development Support. Lt. SAP Entwicklung ist demnach die Nutzung solcher „Vorbrenner“ in diesen Konstellationen wohl nicht unüblich.
 

Das nachfolgende Programm stellt einen solchen "Vorbrenner" dar.

Das Programm startet mit folgendem Selektionsbildschirm:

• Der Kostenrechnungskreis ist mit 1000 vorbelegt.
• Im Feld Kostenstellengruppe kann eine Gruppe oder Selektionsvariante angegeben werden. Es werden nur die Kostenstellen für die Fortschreibung der kumulierten Kosten berücksichtigt, die in der Gruppe enthalten sind. Dies entspricht in der Umlage der Empfängerbezugsbasis.
• Mittels der Kostenartengruppe (Gruppe/Selektionsvariante) kann auf bestimmte Kosten eingeschränkt werden, um z.B. um bereits ausgeführte Umlagen / Abrechnungen nicht als Empfängerbezugsbasis heranzuziehen. Sofern gewünscht kann das Feld leer gelassen werden und das Häkchen Gesamtkosten gesetzt werden. In diesem Fall werden alle Kosten der in der Kostenstellengruppe angegeben Kostenstellen berücksichtigt.
• Geschäftsjahr und Periode müssen angegeben werden. Unter dieser Periode erfolgt die Selektion und Fortschreibung.
• Die statistische Kennzahl ISTKOS ist die statistische Kennzahl, unter der die Kosten fortgeschrieben werden.
   

Coding:

*&---------------------------------------------------------------------*
*& Report ZCO_POST_COSTASSKF
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT zco_post_costasskf.

* Datendeklaration
INCLUDE zco_post_costasskf_top.
* Selektionsbildschirm
INCLUDE zco_post_costasskf_sel.


START-OF-SELECTION.
  IF gs_selection-kstar IS INITIAL AND p_gesam IS INITIAL.
    "Fehlermeldung
  ENDIF.
*Übernahme der Selektionsparameter in Struktur
  gs_selection-kokrs = p_kokrs.
  gs_selection-gjahr = p_gjahr.
  gs_selection-perio = p_perio.
  gs_selection-gesam = p_gesam.
  gs_selection-verto = p_verto.
  gs_selection-stagr = p_stagr.
  LOOP AT s_verfr REFERENCE INTO DATA(ls_verfr).
    APPEND ls_verfr->* TO gs_selection-verfr.
  ENDLOOP.
  IF gs_selection-koset IS INITIAL. gs_selection-koset = '0101' && gs_selection-kokrs && p_1koset. ENDIF.
  IF gs_selection-kstar IS NOT INITIAL AND p_gesam IS INITIAL. gs_selection-kstar = '0102' && gs_selection-kokrs && p_1kstar. ENDIF.

* Start der Verarbeitung
  DATA(lo_instance) = zcl_co_cost2statfig=>get_instance( ).
  lo_instance->start( gs_selection ).

*&---------------------------------------------------------------------*
*& Include          ZCO_POST_COSTASSKF_TOP
*&---------------------------------------------------------------------*

DATA: gv_kosetname TYPE c LENGTH 10,
      gv_kstarname TYPE c LENGTH 10.

DATA: gs_selection TYPE zcl_co_cost2statfig=>ts_selection.

TABLES: csks.

*&---------------------------------------------------------------------*
*& Include          ZCO_POST_COSTASSKF_SEL
*&---------------------------------------------------------------------*

SELECTION-SCREEN BEGIN OF BLOCK b01 WITH FRAME TITLE TEXT-t01.
PARAMETERS: p_kokrs TYPE kokrs MATCHCODE OBJECT csh_tka01 OBLIGATORY DEFAULT 1000.
PARAMETERS: p_1koset  LIKE rksb1-ksgru OBLIGATORY.
*PARAMETERS: p_2koset  LIKE rgsbs-setnr MODIF ID in5.
PARAMETERS: p_1kstar  LIKE rksb1-kagru.
*PARAMETERS: p_2kstar  LIKE rgsbs-setnr MODIF ID in5.
PARAMETERS: p_gesam AS CHECKBOX.
SELECTION-SCREEN SKIP 1.
PARAMETERS: p_gjahr TYPE gjahr OBLIGATORY.
PARAMETERS: p_perio TYPE periode OBLIGATORY.
SELECTION-SCREEN END OF BLOCK b01.

SELECTION-SCREEN BEGIN OF BLOCK b02 WITH FRAME TITLE TEXT-t02.
PARAMETERS: p_stagr TYPE ccss-stagr OBLIGATORY.
PARAMETERS: p_verto TYPE csks-kosar.
SELECT-OPTIONS: s_verfr FOR csks-kosar NO INTERVALS.
SELECTION-SCREEN END OF BLOCK b02.

INITIALIZATION.
* Defaultwert Datum
  SELECT SINGLE lmona FROM tka01
    WHERE kokrs EQ @p_kokrs
    INTO @DATA(gv_periv).
  CALL FUNCTION 'DATE_TO_PERIOD_CONVERT'
    EXPORTING
      i_date         = sy-datum
*     I_MONMIT       = 00
      i_periv        = gv_periv
    IMPORTING
      e_buper        = p_perio
      e_gjahr        = p_gjahr
    EXCEPTIONS
      input_false    = 1
      t009_notfound  = 2
      t009b_notfound = 3
      OTHERS         = 4.
  IF sy-subrc <> 0.
* Implement suitable error handling here
  ENDIF.

* Periodenberechnung
  p_perio = p_perio - 1.
  IF p_perio EQ 0. p_perio = 12. ENDIF.
  IF p_perio EQ 12. p_gjahr = p_gjahr - 1. ENDIF.


AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_1koset.
  CALL FUNCTION 'K_GROUP_SELECT'
    EXPORTING
      class         = '0101'
      field_name    = 'KOSTL                         '
      table         = 'CCSS                          '
    IMPORTING
      setid         = gs_selection-koset
      set_name      = gv_kosetname
    EXCEPTIONS
      no_set_picked = 02.
  IF sy-subrc = 0.
    p_1koset = gv_kosetname.
  ENDIF.

AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_1kstar.
  CALL FUNCTION 'K_GROUP_SELECT'
    EXPORTING
      class         = '0102'
      field_name    = 'KSTAR                         '
      table         = 'CCSS                          '
    IMPORTING
      setid         = gs_selection-kstar
      set_name      = gv_kstarname
    EXCEPTIONS
      no_set_picked = 02.
  IF sy-subrc = 0.
    p_1kstar = gv_kstarname.
  ENDIF.

AT SELECTION-SCREEN.
  IF p_gesam EQ abap_true.
    CLEAR: p_1kstar, gs_selection-kstar, gv_kstarname.
  ENDIF.

AT SELECTION-SCREEN OUTPUT.
  LOOP AT SCREEN.
    IF screen-name = 'P_1KSTAR'.
      IF p_gesam EQ abap_true.
        CLEAR p_1kstar.
        screen-input = '0'.
      ELSE.
        screen-input = '1'.
      ENDIF.
      MODIFY SCREEN.
    ENDIF.
  ENDLOOP.

CLASS zcl_co_cost2statfig DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.

 

    TYPES:
      tr_kosar TYPE RANGE OF csks-kosar .
    TYPES:
      BEGIN OF ts_selection.
    TYPES kokrs TYPE kokrs.
    TYPES koset TYPE rgsbs-setnr.
    TYPES kstar TYPE rgsbs-setnr.
    TYPES gesam TYPE checkbox.
    TYPES gjahr TYPE gjahr.
    TYPES perio TYPE periode.
    TYPES verto TYPE kosar.
    TYPES verfr TYPE tr_kosar.
    TYPES stagr TYPE stagr.
    TYPES END OF ts_selection .

    TYPES BEGIN OF ts_csks.
    TYPES kokrs TYPE kokrs.
    TYPES kostl TYPE kostl.
    TYPES datbi TYPE datbi.
    TYPES bukrs TYPE bukrs.
    TYPES prctr TYPE prctr.
    TYPES kosar TYPE kosar.
    TYPES END OF ts_csks.

    TYPES tt_csks TYPE STANDARD TABLE OF ts_csks WITH DEFAULT KEY
                                                 WITH UNIQUE HASHED KEY k1 COMPONENTS kokrs kostl datbi
                                                 WITH NON-UNIQUE SORTED KEY k2 COMPONENTS kosar.

    TYPES tt_cskb TYPE STANDARD TABLE OF cskb WITH DEFAULT KEY.

    TYPES BEGIN OF ts_costs.
    TYPES kokrs TYPE kokrs.
    TYPES kostl TYPE kostl.
    TYPES bukrs TYPE bukrs.
    TYPES prctr TYPE prctr.
    TYPES kosar TYPE kosar.
    TYPES wrttp TYPE co_wrttp.
    TYPES sum   TYPE coep-wkgbtr.
    TYPES END OF ts_costs.

    TYPES tt_costs TYPE STANDARD TABLE OF ts_costs WITH DEFAULT KEY.

    CLASS-METHODS get_instance
      RETURNING
        VALUE(ro_instance) TYPE REF TO zcl_co_cost2statfig .
    METHODS start
      IMPORTING
        !is_selection TYPE ts_selection .
protected section.
private section.

  data CV_FAILURE type ABAP_BOOL .
  data GT_COSTS type TT_COSTS .
  data CV_VERTO type KOSAR .
  data GR_KSTAR type REP_EAPS_TAB_KSTAR_RANGE .
  data GT_VERTO type TT_CSKS .
  data RT_VERFR type TR_KOSAR .
  data CV_GESAM type CHECKBOX .
  data CV_DATAB type DATEFROM .
  data CV_DATBI type DATETO .
  data CV_GJAHR type GJAHR .
  data CV_KOKRS type KOKRS .
  data CV_PERIO type PERIODE .
  class-data GO_INSTANCE type ref to ZCL_CO_COST2STATFIG .
  data GT_CSKB type TT_CSKB .
  data GR_KOSTL type HRPP_SEL_KOSTL .
  data CV_STAGR type STAGR .
  data GT_RETURN type BAPIRET2_T .

  methods CALCULATE_COSTS .
  methods DBSEL_CSKB
    importing
      !IT_KSTAR type REP_EAPS_TAB_KSTAR_RANGE
    returning
      value(RT_CSKB) type TT_CSKB .
  methods DBSEL_CSKS
    importing
      !IT_KOSTL type HRPP_SEL_KOSTL
    returning
      value(RT_CSKS) type TT_CSKS .
  methods POST_STATFIG .
  methods REVERSE_STATFIGPOST .
  methods SHOW_LOG .
  methods SET_DATA
    importing
      !IS_SELECTION type TS_SELECTION .
  methods SET_KOSTENARTEN
    importing
      !IS_SELECTION type TS_SELECTION .
  methods SET_KOSTENSTELLEN
    importing
      !IS_SELECTION type TS_SELECTION .
  methods SET_SELMAIN
    importing
      !IS_SELECTION type TS_SELECTION .
ENDCLASS.



CLASS ZCL_CO_COST2STATFIG IMPLEMENTATION.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Private Method ZCL_CO_COST2STATFIG->CALCULATE_COSTS
* +-------------------------------------------------------------------------------------------------+
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD calculate_costs.

    DATA: lv_tabix     TYPE sy-tabix,
          ls_costverto TYPE ts_costs,
          lt_costverto TYPE tt_costs.

*   Prüfen, ob bereits eine Fehlersituation vorliegt
    CHECK cv_failure IS INITIAL.
*   Select aus COEP, da hier die Daten mit Vorzeichen vorliegen
    SELECT
      a~kokrs, a~kostl, b~bukrs, b~prctr, b~kosar,
      a~wrttp, SUM( a~wkgbtr ) AS sum "Direkte Summierung möglich, da Werte positiv und negativ vorliegen
      FROM coep AS a
      INNER JOIN csks AS b
      ON a~kokrs EQ b~kokrs AND a~kostl EQ b~kostl
      WHERE a~kokrs EQ @cv_kokrs
      AND   a~lednr EQ '00'
      AND   a~gjahr EQ @cv_gjahr
      AND   a~perio EQ @cv_perio
      AND   a~kstar IN @gr_kstar
      AND   a~kostl IN @gr_kostl
      GROUP BY a~kokrs, b~bukrs, b~prctr, a~kostl, b~kosar, a~wrttp
      INTO CORRESPONDING FIELDS OF TABLE @gt_costs.
*   Buchungskreis 1003 hat Filialkostenstellen, die irrelevant sind, Nullzeilen ignorieren!
    DELETE gt_costs WHERE ( bukrs = '1003' AND kosar EQ cv_verto ) OR sum IS INITIAL.
    DELETE gt_costs WHERE wrttp NE '04'.
*   Verdichtung
    LOOP AT gt_verto REFERENCE INTO DATA(ls_verto).
      CLEAR ls_costverto.
      MOVE-CORRESPONDING ls_verto->* TO ls_costverto.
      LOOP AT gt_costs REFERENCE INTO DATA(ls_costs)
        WHERE bukrs EQ ls_verto->bukrs
        AND   prctr EQ ls_verto->prctr
        AND