Zurück zur Startseite

SAP FEB_FILE_HANDLING: Einheitlicher Import von Bankauszügen (XML & Text)

Erfahren Sie, wie SAP FEB_FILE_HANDLING einen einheitlichen, automatisierten Import vielfältiger Bankauszugsformate ermöglicht, einschließlich XML und länderspezifischer Textformate, Abhängigkeiten vom veralteten Multicash eliminiert und Finanzprozesse für Middle-/Senior-Tech-Spezialisten optimiert.

SAP FEB_FILE_HANDLING: Einheitlicher Import von XML- und Text-Bankauszügen
Advertisement 728x90

SAP-Kontoauszugsimport optimieren: XML- und Textformate mit FEB_FILE_HANDLING vereinheitlichen

In einem Umfeld sich ständig weiterentwickelnder Anforderungen an die Finanzberichterstattung und vielfältiger Kontoauszugsformate ist eine effiziente Automatisierung ihres Imports in SAP von entscheidender Bedeutung. Traditionelle Ansätze stoßen oft an Grenzen, insbesondere bei der Verarbeitung von Textformaten, die veraltete Zwischenkonvertierungen erforderlich machen. Dieser Artikel beleuchtet die Möglichkeiten von FEB_FILE_HANDLING als zentralisierte Lösung für den vereinheitlichten Import sowohl von XML- als auch von spezifischen Text-Kontoauszugsformaten, die den Bedarf an Altsystemen wie Multicash eliminiert und die Zahlungsabwicklung optimiert.

Herausforderungen des traditionellen Kontoauszugsimports in SAP

Historisch gesehen stellte der Import von Kontoauszügen in SAP, insbesondere in Textformaten, mehrere Herausforderungen dar. Das klassische Programm RFEBKA00, das für Dateiuploads verwendet wurde, erforderte oft eine manuelle Bearbeitung und war auf lokale Arbeitsstationen angewiesen. Eine wesentliche Einschränkung für länderspezifische Textformate war die obligatorische Zwischenkonvertierung über Multicash – eine vor über 25 Jahren entwickelte Lösung, die nicht mehr den modernen Automatisierungs- und Integrationsstandards entspricht. Dieser Ansatz verlangsamte den Prozess nicht nur, sondern führte auch zusätzliche Fehlerquellen ein und erforderte spezielles Wartungswissen.

Probleme mit dem traditionellen Ansatz:

Google AdInline article slot
  • Manuelle Bearbeitung: Abhängigkeit von Benutzeraktionen zur Initiierung von RFEBKA00.
  • Veraltete Technologie: Die Notwendigkeit, Multicash für die Konvertierung von Textformaten zu verwenden, was ein technologischer Anachronismus ist.
  • Fragmentierte Formate: Fehlender einheitlicher Ansatz zur Verarbeitung von XML- und Textdateien, was Support und Skalierbarkeit erschwert.
  • Begrenzte Agilität: Verzögerungen beim Empfang und der Verarbeitung von Bankinformationen, was die Geschwindigkeit der Zahlungsabstimmung und die Genauigkeit der Salden beeinflusst.

Diese Faktoren führten zu Ineffizienzen in den Finanzprozessen, Verzögerungen bei der Kontenabstimmung und einer verminderten Transparenz des Cashflows. Das Ziel einer modernen SAP-Infrastruktur ist es, einen einzigen Einstiegspunkt für alle Arten von Kontoauszügen zu schaffen, unabhängig von ihrer Quelle (direkte Bankkommunikation oder Export aus einem „Bank-Client“-System) und ihrem Format.

FEB_FILE_HANDLING Architektur: Die Grundlage für die Vereinheitlichung

FEB_FILE_HANDLING ist ein leistungsstarkes SAP-Tool, das für die Automatisierung des Kontoauszugsimports entwickelt wurde. Ursprünglich für XML-Formate konzipiert, ermöglicht seine flexible Architektur die Erweiterung der Funktionalität zur Verarbeitung beliebiger Textformate, einschließlich länderspezifischer Varianten wie „Client → 1C“ oder belarussischer Anfragetypen 400/600.

Wichtige Verarbeitungsstufen in FEB_FILE_HANDLING:

Google AdInline article slot
  • Dateiverarbeitung (BAdI FEB_BSIMP_FILE): In dieser Phase wird das Dateiformat bestimmt und vor dem Einlesen der Datei eine Vorprüfung durchgeführt.
  • Konvertierung in interne Strukturen (BAdI FEB_BSIMP_BANK_STATEMENT): Dies ist die Hauptphase, in der die Kontoauszugsdatei in die internen SAP-Strukturen konvertiert und im FEBxx-Puffer gespeichert wird. Dieses BAdI ist der „Kern“ des Prozesses.
  • Automatisierte Verarbeitung (RFEBKA00): Nach der Speicherung im Puffer wird das Programm RFEBKA00 automatisch zur weiteren Interpretation und Buchung der Auszüge ausgeführt.

Für spezifische Textformate, die keine Standardimplementierungen aufweisen (im Gegensatz zu XML, MT94x oder BAI), wird die Erweiterung BAdI FEB_BSIMP_BANK_STATEMENT_X verwendet. Darin werden die Methoden GET_BANK_STATEMENTS und SAVE_BANK_STATEMENTS sequenziell aufgerufen.

  • GET_BANK_STATEMENTS: Analysiert Dateiinhalte, teilt sie in einzelne Auszüge auf und identifiziert wichtige Bankinformationen (Buchungskreis, Hausbank, Konto-ID). Für XML-Dateien erfolgt dies über BAdI FIEB_GET_BANK_STMTS_X. Für Textformate ist eine kundeneigene Logik erforderlich.
  • SAVE_BANK_STATEMENTS: Konvertiert Daten in die internen Schnittstellenstrukturen von SAP und speichert sie in FEBxx-Tabellen. Zum Speichern werden die Module FIEB_SAVE_BANK_STMT (für endgültige Auszüge) und FIEB_SAVE_INTRADAY_STMT (für Intraday-Auszüge) verwendet.

Dieser Ansatz vereinheitlicht die Verarbeitung, eliminiert Multicash und integriert alle Auszugstypen in einen einzigen automatisierten Workflow.

DMEE-Integration für die direkte Textformatkonvertierung

Für die direkte Konvertierung von Textdateien in die internen SAP-Strukturen ohne zwischengeschaltetes Multicash wird das DMEE-Tool (Data Medium Exchange Engine) verwendet. DMEE, bereits für die Multicash-Verarbeitung (Baumtyp MCSH) verwendet, kann für neue Zwecke angepasst werden.

Google AdInline article slot

Wichtige Schritte bei der Arbeit mit DMEE:

  • Einen neuen DMEE-Baumtyp anlegen: Es muss ein neuer Baumtyp definiert werden, der sich an den internen Auszugsschnittstellenstrukturen orientiert, die im BAdI FEB_BSIMP_BANK_STATEMENT verwendet werden.
  • Zielstrukturen: Im neuen DMEE-Baum sollten die Zielstrukturen für Positionen Felder aus FEBEP_IF (Struktur für die Auszugspositionsschnittstelle) und für Kopfdaten aus FEBKO_IF (Struktur für die Auszugskopfschnittstelle) sein.
  • Zusätzliche Felder: Es ist wichtig, die Hinzufügung zusätzlicher Felder zu ermöglichen, zum Beispiel für den Verwendungszweck, da ein DMEE-Baum typischerweise nur zwei Zielstrukturen unterstützt.

Beispiel für die Zuordnung der Zielanwendungsstruktur von Kontoauszugspositionen zur Schnittstellenstruktur FEBEP_IF:

  • Felder aus der Textdatei werden direkt den entsprechenden FEBEP_IF-Feldern zugeordnet, wie Buchungsdatum, Betrag, Währung, Belegnummer usw.
  • Dies ermöglicht DMEE, eine direkte Konvertierung der eingehenden Textdatei in ein Format durchzuführen, das FEB_FILE_HANDLING direkt verarbeiten kann.

Die Nutzung von DMEE auf diese Weise umgeht das veraltete Multicash vollständig, vereinfacht die Architektur erheblich und reduziert Risiken. DMEE bietet Flexibilität bei der Konfiguration von Zuordnungen für verschiedene länderspezifische Textformate, wodurch der Konvertierungsprozess transparent und überschaubar wird.

Entwicklung einer vereinheitlichten BAdI-Implementierung für die parallele Verarbeitung

Um die parallele Verarbeitung verschiedener Formate – XML, MT94x, BAI und spezifische Textformate – zu ermöglichen, ist eine kundeneigene Implementierung des BAdI FEB_BSIMP_BANK_STATEMENT erforderlich. Diese Implementierung dient als zentrale Drehscheibe, von der aus sowohl Standardmethoden für bekannte Formate als auch kundeneigene Methoden zur Verarbeitung von Textdateien aufgerufen werden.

Schema der kundeneigenen BAdI FEB_BSIMP_BANK_STATEMENT Implementierung zur Verarbeitung von XML- und Textformaten:

  • Methode GET_BANK_STATEMENTS:

* Für XML-Dateien: Ein direkter Aufruf der Standardmethode GET_BANK_STATEMENTS der BAdI FIEB_GET_BANK_STMTS_X Implementierung.

* Für Textdateien: Verwendung einer kundeneigenen Methode, zum Beispiel SPLIT_AND_PARSE_TXT_FILES. Diese Methode ist für die Analyse der Dateizeilen, die Aufteilung der Datei in logische Auszüge und die Identifizierung von Bankinformationen (Buchungskreis, Hausbank, Konto-ID) zuständig, ähnlich der vorläufigen XML-Analyse.

* Ergebnis: Konvertierung externer Dateien in logische Auszüge, die einen Kopf (mit Systemkontoinformationen) und eine Tabelle von Dateiinhaltszeilen enthalten.

  • Methode SAVE_BANK_STATEMENTS: Diese Methode hat eine Doppelfunktion: die Konvertierung logischer Auszugsdateien in interne Schnittstellenstrukturen und deren Speicherung im Datenpuffer (FEBxx-Tabellen).

* Parallele Konvertierung:

* Für XML-Formate: Sequenzieller Aufruf der Transformationsmodule FIEB_READ_MAPP_X und FIEB_MAPPING_X, die auch in der BAdI FIEB_GET_BANK_STMTS_X Implementierung verwendet werden.

* Für Textformate: Aufruf einer kundeneigenen Methode, zum Beispiel CALL_DMEE_CONVERT. Diese Methode implementiert den Aufruf des Standard-Hauptkonvertierungsmoduls DMEE_PROCESS_INCOMING_FILE_ABA und der DMEE-Methoden zur Verarbeitung eingehender Dateien (PROCESS_INPUT_DME vor der Konvertierung und PROCESS_OUTPUT_DME danach).

* Konvertierungsergebnis: Alle Auszüge, unabhängig von ihrem ursprünglichen Format, werden in eine vereinheitlichte interne Schnittstellenstruktur (FEBxx_IF-Strukturen) überführt.

* Speichern im Puffer: Über eine gemeinsame Methode, z.B. FEB_SAVE_BANK_STATEMENT, für jedes Auszugsformat. Abhängig von den Buchungsparametern des Auszugs werden FIEB_SAVE_BANK_STMT (für endgültige Auszüge, die in Bereich 0001 gebucht werden) oder FIEB_SAVE_INTRADAY_STMT (für Intraday-Auszüge) aufgerufen.

Dieser Ansatz stellt sicher, dass alle Kontoauszüge einheitlich verarbeitet werden, bietet einen hohen Automatisierungsgrad und minimiert manuelle Eingriffe.

Vorteile und Zukunftsaussichten des zentralisierten Imports

Die Implementierung eines vereinheitlichten Kontoauszugsimportsystems über FEB_FILE_HANDLING mit DMEE-Unterstützung für Textformate bringt erhebliche Vorteile für die Finanzoperationen eines Unternehmens.

Wesentliche Vorteile:

  • Einheitlicher Einstiegspunkt: Alle Kontoauszüge, unabhängig von Format (XML, MT94x, BAI, länderspezifischer Text) und Quelle, werden über einen einzigen FEB_FILE_HANDLING-Mechanismus verarbeitet.
  • Eliminierung von Multicash: Einstellung der veralteten Zwischenkonvertierung über Multicash, wodurch die Architektur vereinfacht und die Wartungskosten gesenkt werden.
  • Automatisierung: Ein vollständig automatisierter Prozess vom Dateieingang bis zur Speicherung im SAP-Puffer und der anschließenden Buchung über RFEBKA00.
  • DMEE-Flexibilität: Die Möglichkeit, beliebige Zuordnungen für alle Textauszugsformate mithilfe des flexiblen DMEE-Tools zu konfigurieren.
  • Erhöhte Agilität: Schnellere Verarbeitung und Abstimmung von Zahlungen, verbesserte Genauigkeit der Finanzinformationen und reduzierte operationelle Risiken.

Diese Architektur ermöglicht es Unternehmen, vielfältige Bankdaten effektiv zu verwalten, die Finanzberichterstattung zu verbessern und eine präzisere und zeitnahere Entscheidungsfindung zu gewährleisten. Zukünftige Entwicklungsperspektiven umfassen eine weitere Integration mit Dokumentenmanagementsystemen und die Erweiterung der Analysefähigkeiten basierend auf eingehenden Daten.

— Editorial Team

Advertisement 728x90

Weiterlesen