Varianten & Job-Planung

Selektionsvarianten, dynamische Datumsfelder und Job-Planung in SM36.

Übersicht

Damit der Extractor-Report automatisiert laufen kann, werden zwei Dinge benötigt:

1. Selektionsvariante – speichert die Selektionsparameter (welche Datentypen, welcher Zeitraum, welche Buchungskreise)

2. Hintergrundjob (SM36) – startet den Report periodisch mit der hinterlegten Variante

1. Selektionsvariante anlegen

Schritt-für-Schritt

1. SE38 → Report ZFI_BILENDO_EXPORT_V2 aufrufen → F8 (Ausführen)

2. Selektionsmaske befüllen:

   • P_KNA1 = X (Kundenstamm)

   • P_BSID = X (Offene Posten)

   • P_BSAD = X (Ausgeglichene Posten)

   • P_DELTA = X (Deltaladung)

   • S_BUKRS = gewünschte Buchungskreise

   • Datumsfelder: → dynamisch (siehe nächster Abschnitt)

3. Menü: Springen → Varianten → Als Variante sichern

4. Variantenname: z. B. BILENDO_DAILY_DELTA

5. Beschreibung: z. B. Bilendo Täglicher Delta-Export

6. Sichern

Empfohlene Selektionswerte

2. Dynamische Datumsfelder konfigurieren

Fixe Datumswerte in der Variante führen zu veralteten Selektionen. Stattdessen müssen Selektionsvariablen verwendet werden, die bei jedem Lauf das aktuelle Datum berechnen.

Welche Felder dynamisch setzen?

Anleitung: Dynamisches Datum in Variante hinterlegen

1. Variante im Änderungsmodus öffnen

2. Button "Attribute" klicken (oder Menü: Springen → Varianten → Attribute)

3. In der Spalte "Selektionsvariable" den Cursor auf das Feld S_CPUDT (Low-Wert) setzen

4. F4-Wertehilfe aufrufen

5. Variable auswählen:

   • D = Aktuelles Datum (für den "Bis"-Wert)

   • D mit Offset -7 = Aktuelles Datum minus 7 Tage (für den "Von"-Wert)

6. Gleiches Vorgehen für S_AUGDT

7. Felder werden danach als nicht editierbar (grau hinterlegt) dargestellt – das ist korrekt

8. Variante sichern

Typische Konfiguration

S_CPUDT (Erfassungsdatum):
  Von: D (aktuelles Datum) - 7 Tage
  Bis: D (aktuelles Datum)

S_AUGDT (Ausgleichsdatum):
  Von: D (aktuelles Datum) - 7 Tage
  Bis: D (aktuelles Datum)

Empfehlung: Mindestens 7 Tage Überlappung verwenden. In SAP können Buchungen rückwirkend erfasst werden – zu enge Zeitfenster führen zu Datenlücken in Bilendo.

3. Selektionslogik im Detail

Offene Posten (BSID)

Die Klasse ZCL_FI_BILENDO_ASSIST_V2 (Methode get_bsid) selektiert wie folgt:

Wenn CPU-Datum (S_CPUDT) gefüllt und nur 1 Tag abdeckt (wegen Uhrzeit):

• Selektion aller Belege mit CPUDT IN S_CPUDT UND (falls angegeben: CPUTM IN S_CPUTM)

• ODER Änderungsdatum (AEDAT) IN S_CPUDT (Änderungen ohne Uhrzeit)

Wenn Buchungsdatum (S_BUDAT) gefüllt:

• Selektion aller Belege mit BUDAT IN S_BUDAT

• ODER Änderungsdatum (AEDAT) IN S_BUDAT

Ausgeglichene Posten (BSAD)

Wenn CPU-Datum (S_CPUDT) gefüllt:

• Selektion via CPUDT IN S_CPUDT (+ optional CPUTM)

• ODER Änderungsdatum (AEDAT) IN S_CPUDT

Wenn Ausgleichsdatum (S_AUGDT) gefüllt:

• Selektion via AUGDT IN S_AUGDT

• ODER Änderungsdatum (AEDAT) IN S_AUGDT

Wenn Ausgleichsbeleg (S_AUGBL) gefüllt:

• Selektion über mehrere Ausgleichsbelege möglich (für Nachselektion)

Kundenstamm (KNA1)

• Generell über CPU-Datum (S_CUSDT) selektiert

• Berücksichtigt Uhrzeit bei der Selektion → Variante mit genau 1 Tag pflegen

• Änderungshistorie wird nicht explizit geprüft (KNA1 hat kein AEDAT auf Feldebene)

4. Job einplanen (SM36)

Schritt-für-Schritt

1. Transaktion SM36 aufrufen

2. Jobname vergeben: BILENDO_EXPORT_DAILY

3. Jobklasse: A (höchste Priorität) oder B (normal)

Step definieren

1. Button "Schritte" → "ABAP/4-Programm"

2. Eintragen:

   • Programmname: ZFI_BILENDO_EXPORT_V2

   • Variante: BILENDO_DAILY_DELTA

3. "Übernehmen" → Step wird angelegt

Mehrere Steps für verschiedene Buchungskreise oder verschiedene Reports (z. B. erst Export, dann Import) können in einem Job hintereinander geschaltet werden.

Startbedingung

1. Button "Startbedingung" → "Datum/Uhrzeit"

2. Startdatum: Heutiges Datum (oder nächster gewünschter Tag)

3. Startuhrzeit: z. B. 03:00:00 (vor dem Bilendo-Import-Fenster)

4. Häkchen "Periodisch" setzen

5. Periode: "Täglich" → "Sichern"

Job freigeben

1. Zurück im Hauptbild: Button "Sichern"

2. Job erscheint mit Status "Freigegeben" in SM37

Jobüberwachung (SM37)

5. Job-Konfigurationsvarianten

Variante A: Ein Job für alle Buchungskreise

Job: BILENDO_EXPORT_DAILY
  Step 1: ZFI_BILENDO_EXPORT_V2 / Variante: BILENDO_DAILY_DELTA
          (S_BUKRS enthält alle Buchungskreise)
  Startbedingung: Täglich 03:00

Variante B: Separate Jobs je Buchungskreis

Job: BILENDO_EXPORT_BK1001
  Step 1: ZFI_BILENDO_EXPORT_V2 / Variante: BILENDO_DELTA_1001
  Startbedingung: Täglich 03:00

Job: BILENDO_EXPORT_BK2001
  Step 1: ZFI_BILENDO_EXPORT_V2 / Variante: BILENDO_DELTA_2001
  Startbedingung: Täglich 03:15

Variante C: Export + Import in einem Job

Job: BILENDO_SYNC_DAILY
  Step 1: ZFI_BILENDO_EXPORT_V2 / Variante: BILENDO_DAILY_DELTA
  Step 2: ZFI_BILENDO_IMPORT_V2 / Variante: BILENDO_IMPORT_DAILY
  Startbedingung: Täglich 03:00

Hinweis: Variante C ist nur sinnvoll wenn die Bilendo-seitigen Rückschreibedateien zum Zeitpunkt des Joblaufs bereits auf dem Applikationsserver liegen. Andernfalls sollte der Import-Job zeitversetzt laufen.

6. Variante für Zwei-Stufen-Delta (6-stündlich)

Bei Verwendung der verbesserten Zwei-Stufen-Delta-Logik (→ 04 - Extractor Report#Verbesserte Delta-Logik Zwei-Stufen-Selektion) wird der Job alle 6 Stunden eingeplant. Die Delta-Fenster werden programmatisch in den Methoden get_open_delta() und get_cleared_delta() berechnet – dynamische Datumsfelder in der Variante sind daher nicht mehr erforderlich.

Variante: BILENDO_DELTA_6H

SM36-Einplanung (periodisch alle 6 Stunden)

1. SM36 → Jobname: BILENDO_EXPORT_6H

2. Step: ZFI_BILENDO_EXPORT_V2 / Variante BILENDO_DELTA_6H

3. Startbedingung → Datum/Uhrzeit → Startzeit 00:00:00

4. Häkchen "Periodisch" → Periode: "Stündlich" → Stundenwert: 6

5. Sichern

Die BSAD-Selektion verwendet immer ein 24h-Fenster (AUGDT ≥ gestern), unabhängig von der Lauffrequenz. Dadurch entsteht ein vierfacher Overlap, der Robustheit bei Fehlern garantiert.

7. Variante für Initial-/Vollladen

Für die initiale Erstbefüllung oder einen vollständigen Neuladen wird eine separate Variante benötigt:

Variantenname: z. B. BILENDO_INITIAL_FULL

⚠️ Achtung: Ein Vollladen kann je nach Datenmenge erhebliche Laufzeit und Systemlast erzeugen. Vor der Ausführung in PRD mit SAP-Basis abstimmen.