ale

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.