Zum Hauptinhalt springen

Beispiele

Hinweis

Diese Beispiele zeigen Ihnen den Ablauf zur Einrichtung von Extraction Packages. Wir haben die Übung für eine verständlichere Einführung „erweitert“. Die Oberfläche und Farben wurden in neueren Versionen angepasst. Daher kann die Darstellung auf den Screenshots leicht von Ihrer Version abweichen.

Beispiel 1 – Einfaches Package​

Welche Daten möchten wir wissen oder extrahieren?​

  • Extraktion aller bereits gebuchten Positionen
  • Von allen produktiven Buchungskreisen

Was benötigen wir für diese Extraktion bzw. woher bekommen wir diese Daten?​

  • Tabelle mit Buchungskreisen
  • Tabelle mit bereits gebuchten Positionen aus dem FI-Dictionary
  • Filter auf das Merkmal, ob der Buchungskreis produktiv ist

Welche Package-Elemente benötigen wir?​

Wir beginnen mit der Integration von T001 (SAP-Tabelle der Buchungskreise) als Tabelle. Anschließend wählen wir alle Felder aus. Zusätzlich verwenden wir die BSAK-Tabelle, um die ausgeglichenen Posten zu extrahieren – diese wird ebenfalls als Tabelle eingebunden. Da wir ausschließlich die Buchungskreise wünschen, die bereits produktiv verwendet werden, erstellen wir einen Filter – in diesem Beispiel nennen wir den Filter Is_Prod. Abschließend legen wir ein Repository an, in dem diese Buchungskreise nach dem ersten Schritt (Extraktion aller produktiven Buchungskreise) gespeichert werden, um die nächste Extraktion durchführen zu können – in diesem Beispiel nennen wir das Repository BuKrs (deutsche Entsprechung zu CCode).

Nach diesen Schritten haben wir die folgenden Elemente auf der linken Seite:
nexus_ps_example_1

Filter​

Im nächsten Schritt legen wir den Filter fest. Wir bestimmen darin, dass das Feld XPROD in der T001 aktiv sein muss, also den Wert X enthalten muss; als Typ wählen wir Fixed Value. Da es sich um ein Zeichen handelt, ist der DataType String, und die Condition ist Equal, da wir exakt nach dem Wert X suchen. Wir geben jetzt den Wert X ein und legen bei den Tabellenbeziehungen fest, dass dieser Filter auf der Tabelle T001 für das Feld XPROD angewendet wird.

Der Detailbereich auf der rechten Seite sieht nun folgendermaßen aus (bei Auswahl des Filters links):
nexus_ps_example_2

Repository​

Jetzt filtern wir alle Einträge der Tabelle T001, deren Buchungskreise aktiv sind (XPROD = X). Diese Daten müssen wir für die weitere Nutzung temporär speichern. Dazu nutzen wir das Repository BuKrs. Wir fügen dem Repository die Felder hinzu, die es enthalten soll, woher die Inhalte kommen und bei welchen anderen Tabellen diese Werte weiterverwendet werden.

Deshalb fügen wir zuerst ein Feld CCode ein – würden wir dieses Feld BUKRS nennen, würde das Auto-Mapping für die Quell- und Zieltabellen greifen. In diesem Beispiel machen wir dies aber zunächst manuell. Danach legen wir fest, dass die Quelltabelle T001 ist – daraus stammen unsere Daten, die wir im Repository speichern. Zuletzt legen wir fest, dass die BSAK-Tabelle die Zieltabelle ist. Die Werte aus diesem Repository werden in dieser Tabelle weiterverwendet.

Rechts sehen Sie neben den jeweiligen Tabellennamen ein ⚙️. Dieses ⚙️ steht für Custom Mapping, d. h. Sie müssen das Feld aus der jeweiligen Tabelle mit dem Feld des Repositorys Link.

Am Ende sieht die Detailansicht des Repositorys so aus:
nexus_ps_example_3

Durch Klick auf ⚙️ öffnet sich ein Fenster, in dem Sie die Werte manuell zuordnen können.

Tabellen​

Betrachten wir nun den Detailbereich der Tabellen T001 und BSAK:
nexus_ps_example_4

Hier sieht man bei T001 die ausgewählten Felder, die ersten beiden sind die Primary Keys und das dritte ist das Merkmal, ob der Buchungskreis produktiv genutzt wird. Der Filter bezieht sich auf das Feld XPROD; die gefilterten Buchungskreise landen im Target Repository BuKrs.

Etwas anders verhält es sich im Detailbereich der BSAK. Hier wird abhängig von der Abhängigkeit der Daten aus dem Repository BuKrs gefiltert:
nexus_ps_example_5

Ergebnis​

Am Schluss sieht die Elementübersicht in der Mitte so aus:
nexus_ps_example_6

Kurz erklärt: Der Filter mit dem Namen Is_Prod filtert die Einträge aus der T001. Diese gefilterten Einträge landen im Repository BuKrs, welches wiederum zum Filtern der Einträge aus der BSAK verwendet wird. Am Ende erhalten Sie eine Liste der gebuchten Positionen aus der BSAK, die einem produktiven Buchungskreis zugeordnet sind.


Beispiel 2 – Fortgeschrittenes Package​

Welche Daten möchten wir wissen oder extrahieren?​

  • Suche nach allen Bestellungen (PO) aus der EKKO-Tabelle
  • Durch Extraktion aller POs mit offenen oder bereits bezahlten Rechnungsbelegen
  • Aus einem oder mehreren Geschäftsjahren
  • Von deutschen Lieferanten

Was benötigen wir für diese Extraktion bzw. woher bekommen wir diese Daten?​

  • Tabellen:
    • Kreditorenstammdaten
    • Buchhaltung: Sekundärindex für Kreditoren (Ausgeglichene Posten)
    • Buchhaltung: Sekundärindex für Kreditordaten (Offene Posten)
    • Buchhaltungsbeleg-Segment
    • Einkaufsbeleg-Kopf
  • Filter:
    • Lieferanten aus Deutschland
    • Geschäftsjahr
  • Repositories (werden während der Erstellung des Packages ergänzt):
    • ...

Welche Package-Elemente benötigen wir?​

Wir beginnen mit den benötigten Tabellen:

  • LFA1: Kreditorenstammdaten
  • BSAK: Buchhaltung – Sekundärindex für Kreditoren (Ausgeglichene Posten)
  • BSIK: Buchhaltung – Sekundärindex für Kreditordaten (Offene Posten)
  • BSEG: Buchhaltungsbeleg-Segment
  • EKKO: Einkaufsbeleg-Kopf

Anschließend legen wir die Filter an und benennen sie entsprechend:

  • LFA1_DE: Filter für deutsche Lieferanten
  • GJAHR: Geschäftsjahr

Die Elementliste auf der linken Seite sollte nun so aussehen:
nexus_ps_example_7

Filter LFA1_DE​

Wir legen den Filter LFA1_DE an und geben an, auf welche Tabellen und Felder gefiltert werden soll.

Wir setzen einen Fixed Value, da wir Lieferanten eines bestimmten Landes suchen (dieser Wert ändert sich nicht). Die Condition ist Equal, da wir nach dem genauen Wert suchen. Als DataType wählen wir string, weil es sich um Zeichen handelt. Als Value geben wir DE an, den Länderschlüssel für Deutschland. Schließlich ergänzen wir die Table Relation zu LFA1 und zum Feld LAND1, da wir darauf filtern möchten.

Nun sollte der Filter LFA1_DE so aussehen:
nexus_ps_example_8

Filter GJAHR​

Jetzt richten wir den zweiten Filter für das Geschäftsjahr ein. Da wir einen speziellen Filter-Typ namens Fiscal Year haben, können wir diesen nutzen. In diesem Fall müssen die gewünschten Geschäftsjahre nicht im Package selbst, sondern später im Task eingegeben werden. Auch hier legen wir zwei Table Relations an: eine für BSAK und eine für BSIK, jeweils mit dem Feld GJAHR.

Nun sollte der Filter GJAHR so aussehen:
nexus_ps_example_9

Repository LFA1_Kred_DE​

Nachdem wir die Tabellen und Filter erfolgreich angelegt haben, widmen wir uns jetzt den Repositories, die für das Zwischenspeichern der Ergebnisse benötigt werden, mit denen wir weiterarbeiten können.

Wir erstellen das Repository LFA1_Kred_DE, um die Ergebnisse der gefilterten Tabelle LFA1 mit dem Filter LFA1_DE temporär zu speichern. Für das Repository definieren wir folgende Einstellungen:

  • Felder
    • LIFNR: Lieferantennummer der deutschen Lieferanten
  • Ziel-Tabellen
    • BSIK: automatische Zuordnung der Felder über LIFNR
    • BSAK: automatische Zuordnung der Felder über LIFNR

Wir haben nun unser erstes Repository, das alle Lieferantennummern deutscher Lieferanten enthält. Es sollte folgendermaßen aussehen:
nexus_ps_example_10

Repository Belnr​

Jetzt legen wir ein weiteres Repository an und nennen es Belnr – hier möchten wir die in den Tabellen BSAK und BSIK gefundenen Belegnummern speichern. Wir erhalten die Belegnummern, indem wir diese Tabellen auf die gerade gefundenen Lieferantennummern (gespeichert im Repository LFA1_Kred_DE) und die im Task angegebenen Geschäftsjahre filtern.

Doch jetzt müssen wir aufpassen. Würden wir hier nur die Belegnummer speichern, würden wir entweder nicht alle Belegnummern erhalten oder sehr viele Duplikate erzeugen. Denn die Belegnummer kann sich in unterschiedlichen Buchungskreisen und Geschäftsjahren wiederholen. Um dem entgegenzuwirken, speichern wir im Repository nicht nur die Belegnummer, sondern auch das Geschäftsjahr und den Buchungskreis.

Da wir diese Informationen aus den Tabellen BSAK und BSIK erhalten, geben wir diese beiden als Source Tables an. Mit dem Custom Mapping können wir überprüfen, ob die Felder korrekt zugeordnet sind.

Nun haben wir die Belegnummern deutscher Lieferanten aus den gewünschten Geschäftsjahren im Repository Belnr abgelegt. Es sollte jetzt so aussehen:
nexus_ps_example_11

Tabelle BSEG​

Jetzt suchen wir nach den Bestellnummern (POs) in der Tabelle BSEG. Das bedeutet, dass die BSEG als Dependency unseres Repositorys Belnr gefiltert wird. Aufgrund der unterschiedlichen Bezeichnung des Feldes für den Buchungskreis muss hier erneut das Custom Mapping durchgeführt werden:
nexus_ps_example_12

Repository EBELN​

Die erhaltenen Daten aus der BSEG schreiben wir nun in dieses abschließende Repository, das wir EBELN nennen. Da die Bestellnummern in unserem Beispiel eindeutig sind, benötigen wir hier nur ein Feld mit dem Namen EBELN.

Wir geben an, dass die hier gespeicherten Daten aus der BSEG-Tabelle stammen (daher als Source Table):
nexus_ps_example_13

Und da wir jetzt auf die korrekte Groß-/Kleinschreibung geachtet haben, greift das automatische Mapping erneut.

Tabelle EKKO​

Abschließend möchten wir die EKKO-Tabelle mit den in der BSEG gefundenen Bestellnummern filtern, um alle weiteren Bestellkopf-Informationen zu erhalten. Daher fügen wir jetzt die EKKO hinzu. Da wir hier alle verfügbaren Informationen extrahieren möchten, wählen wir jetzt alle Felder über den Button All aus. Diese Tabelle wird erneut abhängig von der Dependency des vorherigen Repositorys EBELN gefiltert:
nexus_ps_example_14

Ergebnis​

Und et voilà! Am Ende erhalten Sie alle relevanten Bestellkopf-Daten der gewünschten Geschäftsjahre deutscher Lieferanten.

Wenn wir einen Blick auf die Elementübersicht in der Mitte werfen, sieht das Ganze so aus:
nexus_ps_example_15

Mit dieser Konfiguration erstellt der Task folgende Result Tables:

  • LFA1
  • BSAK
  • BSIK
  • BSEG
  • EKKO

Wenn Sie wirklich nur die Bestellkopfdaten benötigen, können Sie die Tabellen LFA1, BSAK & BSIK sowie BSEG auch als Virtual Tables deklarieren. Diese werden dann am Ende eines Extraction Runs nicht mehr als Result Tables gespeichert.