Architektur & Datenfluss

Systemlandschaft, Datenfluss und Verantwortlichkeiten im Überblick.

Systemlandschaft

Die Bilendo SAP Integration operiert in drei Zonen:

Zone 1: SAP ERP

Das Quellsystem. Hier werden Stammdaten (KNA1/KNB1), offene Posten (BSID), ausgeglichene Posten (BSAD) und optional Aufträge (VBAK/VBAP) gelesen und als flache TXT-Dateien auf den SAP-Applikationsserver geschrieben.

Beteiligte SAP-Module: FI-AR (Accounts Receivable), optional FI-GL und SD (Sales & Distribution).

Zone 2: Middleware / Datentransport

Dateien werden vom SAP-Applikationsserver per SFTP an Bilendo übertragen. Typische Middleware-Optionen:

Zone 3: Bilendo

Die SaaS-Plattform liest die Dateien vom SFTP-Server ein und verarbeitet sie. Bilendo stellt seinerseits CSV-Dateien für die Rückintegration bereit.

Datenfluss: Export (SAP → Bilendo)

SAP-Tabellen                   SAP Applikationsserver          Bilendo SFTP            Bilendo
─────────────                  ──────────────────────          ────────────            ───────
KNA1/KNB1   ─┐
             ├─ ZCL_FI_BILENDO_ASSIST_V2
BSID        ─┤     ↓                        
             │  get_kna1()    → kna1_file_to_server()  → CC_Customers_...txt ──→ SFTP ──→ Import
             │  get_bsid()    → bseg_file_to_server()  → CC_open_...txt      ──→ SFTP ──→ Import
BSAD        ─┤  get_bsad()    → bseg_file_to_server()  → CC_cleared_...txt   ──→ SFTP ──→ Import
             │
VBAK/VBAP   ─┘  get_orders()  → orders_file_to_server() → CC_orders_...txt   ──→ SFTP ──→ Import

Ablauf im Detail

1. SM36-Job startet den Report ZFI_BILENDO_EXPORT_V2 (typisch: täglich 03:00 Uhr)

2. Report liest die Selektionsparameter aus der Variante (z. B. BILENDO_DAILY_DELTA)

3. Report selektiert alle relevanten Buchungskreise aus T001 (WHERE rcomp <> '')

4. Je Buchungskreis (Loop):

   • set_bukrs() – setzt den aktiven Buchungskreis in der Klasse

   • get_kna1() – selektiert Kundenstammdaten (KNA1 JOIN KNB1 JOIN ADR6)

   • kna1_file_to_server() – schreibt TXT-Datei auf Applikationsserver

   • get_bsid() – selektiert offene Posten (BSID + BSEG Ergänzungen)

   • get_additional() – ergänzt Zusatzfelder (VKORG, BKTXT, VBELN, AUFNR, etc.)

   • bseg_file_to_server() – schreibt TXT-Datei

   • get_bsad() – selektiert ausgeglichene Posten (analog BSID)

   • get_additional() + bseg_file_to_server() – analog

   • get_orders() – selektiert Aufträge (VBAK + VBAP + VBUK + weitere Tabellen)

   • orders_file_to_server() – schreibt Orders-TXT-Datei

5. Middleware (CPI/Seeburger/Lobster) transferiert die Dateien per SFTP

6. Bilendo importiert die Dateien automatisch

Datenfluss: Re-Integration (Bilendo → SAP)

Bilendo                    Bilendo SFTP           SAP Applikationsserver           SAP
───────                    ────────────           ──────────────────────           ───
Plattform ──→ Export ──→   bilendo_credit_limits       ──→ SFTP ──→ Download
                           bilendo_credit_informations ──→ SFTP ──→ Download
                           bilendo_securities          ──→ SFTP ──→ Download     ┐
                           bilendo_customers           ──→ SFTP ──→ Download     ├─ ZFI_BILENDO_IMPORT_V2
                           bilendo_journal_entries     ──→ SFTP ──→ Download     ┘    → BAPI/BDC

Ablauf Re-Integration

1. Bilendo legt CSV-Dateien auf dem SFTP-Server ab (→ Details in 09 - Re-Integration Felder)

2. Middleware lädt Dateien in das SAP-Eingangsverzeichnis (/usr/sap/<SID>/COMM/Bilendo_IN/)

3. Report ZFI_BILENDO_IMPORT_V2 wird gestartet (manuell oder per Job)

4. Klasse liest CSV-Dateien ein (get_files() + read_csv())

5. Rückschreibung:

   • credit_limit_change() – Kreditlimit + Risikokategorie auf KNB5/KNKK

   • customer_change() – Mahnstufe, Mahnsperre, Versichertes Obligo auf KNB1/KNKA

   • doc_change() – Mahnstufe/-datum auf Belegebene (BSEG)

6. Optional: delete_files() – Bereinigung der verarbeiteten Dateien

Datentypen

Die Integration transportiert vier Kerndatentypen. Die vollständige Felddefinition findet sich in 06 - Datenspezifikation.

Delta-Strategie

Bilendo arbeitet nicht mit echtem Delta (kein Change-Pointer, kein IDOC). Stattdessen wird bei jedem Lauf ein überlappender Zeitraum selektiert. Die Integration bietet zwei Delta-Modi:

Einfache Delta-Selektion (v2.1 Standard)

Selektion über CPUDT/BUDAT mit überlappenden Zeitfenstern (typisch: 7 Tage). Einfach zu konfigurieren, hat aber Schwächen bei der Erkennung von Ausgleichsereignissen an Belegen, deren Erfassungsdatum außerhalb des Fensters liegt.

Zwei-Stufen-Delta-Selektion (empfohlen)

Die verbesserte Variante verwendet eine zweistufige Logik: zunächst werden über BKPF bzw. AUGDT die relevanten Belegkontexte identifiziert, anschließend werden die zugehörigen Positionen aus BSID/BSAD geladen. Dieses Verfahren ist robust gegen Fehlkonfiguration und erfasst auch Ausgleiche an alten Belegen zuverlässig.

Für Details und ABAP-Code → 04 - Extractor Report#Verbesserte Delta-Logik Zwei-Stufen-Selektion.

Die Overlap-Steuerung erfolgt über die Selektionsvariante (→ 07 - Varianten & Job-Planung).

Berechtigungen

Für die Einrichtung und den Betrieb werden folgende Berechtigungen benötigt: