Beispiele
aktualisiert 6/12/23
von
Stephanie Krenz
Sicherlich können wir die beiden Beispielen auf einem kürzeren Weg an unsere Daten gelangen. Für einen übersichtlicheren Einstieg haben wir das Ganze aber etwas "verlängert".
In den folgenden Abschnitten sehen wir uns das Ganze einmal praktisch anhand von Beispielen an.
Beispiel 1 -> einfaches Package
Welche Daten möchten wir wissen bzw. extrahieren?
- Extraktion aller bereits ausgeglichenen Posten
- aller produktiven Buchungskreise
Was benötigen wir für diese Extraktion bzw. woher bekommen wir diese Daten?
- Tabelle mit Buchungskreisen
- Tabelle mit ausgeglichenen Posten aus FI-Dictionary
- Filter auf das Kennzeichen, ob Buchungskreis produktiv ist
Beginnen wir mit der Einbindung der T001 (SAP-Tabelle der Buchungskreise) als Tabelle.
Des Weiteren verwenden wir für die Extraktion der augeglichenen Posten die Tabelle BSAK, auch diese wird als Tabelle eingebunden.
Da wir nur die Buchungskreise wollen, die bereits produktiv genutzt werden, erstellen wir einen Filter -> für dieses Beispiel nennen wir den Filter Is_Prod.
Zu guter Letzt erstellen wir ein Repository, in dem nach dem ersten Schritt (Extraktion aller produktiven Buchungskreise) ebendiese Buchungskreise abgespeichert werden, um die nächste Extraktion durchführen zu können -> das Repository nennen wir in diesem Beispiel BuKrs.
Wir haben also nach diesen Schritte links die folgenden Elemente:
Im nächsten Schritt stellen wir den Filter ein. Da wir bei diesem Filter festlegen, dass das Feld XPROD in der T001 aktiv sein, also den Wert X enthalten muss, geben wir als Type Fixed Value ein. Da es sich um ein Zeichen handelt, ist der DataType String und die Condition Equal, da wir genau den Wert X suchen.
Als Value geben wir nun das X an und in den Table Relations legen wir fest, dass dieser Filter in der Tabelle T001 für das Feld XPROD gesetzt wird. Damit sieht der Detailbereich im rechten Bereich wie folgt aus (bei der Wahl des Filters links):
Wir filtern nun also aus der Tabelle T001 alle Einträge, deren Buchungskreise aktiv (XPROD = X) ist. Diese Daten müssen wir zur weiteren Verwendung zwischenlagern. Das tun wir im Repository BuKrs.
Wir fügen in das Repository ein, welche Felder es beinhalten soll, woher diese Inhalte kommen und für welche weitere Tabelle diese Werte verwendet werden.
Daher fügen wir zuerst ein Feld CCode ein -> würden wir das Feld BUKRS nennen, würde für die Source- und Target-Tables das Auto-Mapping greifen. In diesem Bespiel machen wir das aber erst einmal manuell.
Anschließend legen wir fest, dass die Source-Table die T001 ist -> da kommen unsere Daten her, die wir in diesem Repository ablegen.
Zu guter Letzt legen wir fest, dass die Tabelle BSAK die Target-Table ist. In dieser werden die Werte aus diesem Repository weiter verwendet.
Du siehst neben den jeweiligen Tabellennamen weiter rechts ein C. Dieses C steht für Custom Mapping, das heißt, Du musst die Verknüpfung zwischen dem Feld aus der jeweiligen Tabelle mit dem Feld aus dem Repository verknüpfen.
Am Ende sieht die Detailansicht des Repositories so aus:
Der Klick auf C öffnet ein Fenster mit der Möglichkeit, im Bereich Identity die Werte zu verknüpfen.
Werfen wir nun noch einen Blick in den Detailbereich der Tabellen T001 und BSAK:
Hier für die T001 siehst du die selektierten Felder, die ersten beiden sind die Primärschlüssel und das dritte das Kennzeichen dafür, ob der Buchungskreis produktiv eingesetzt wird. Der Filter zielt auf das Feld XPROD und die gefilterten Buchungskreise landen im Target Repository BuKrs.
Im Detailbereich der BSAK sieht es etwas anders aus:
Hier werden die Daten in Abhängigkeit (Dependency) der Daten aus dem Repository BuKrs gefiltert.
Am Schluss sieht die Elementübersicht in der Mitte wie folgt aus:
Die Kurzerklärung hier ist:
Der Filter Is_Prod filtert die Einträge aus der T001. Diese gefilterten Einträge landen im Repository BuKrs und mit dieser werden die Einträge aus der BSAK gefiltert.
Am Ende erhältst Du so eine Liste der ausgeglichenen Posten aus der BSAK, die einem produktiven Buchungskreis zugeordnet sind.
Beispiel 2 -> fortgeschrittenes Package
Welche Daten möchten wir wissen bzw. extrahieren?
- Suche aller PO-Dokumentnummern (Bestellnummern) aus der Tabelle EKKO
- durch die Extraktion aller Bestellnummern mit offenen oder bereits beglichenen Rechnungsbelegen
- von einem oder mehreren Geschäftsjahr(en)
- von Lieferanten aus Deutschland
Was benötigen wir für diese Extraktion bzw. woher bekommen wir diese Daten?
- Tabellen:
- Lieferantenstammdaten
- ausgeglichene Posten
- offene Posten
- Belegsegment
- Einkaufsbelegkopf
- Filter:
- Lieferanten aus Deutschland
- Geschäftsjahr
- Repositories (füllen wir im Laufe der Erstellung des Pakets):
- ...
Suchen wir uns fürs Erste alle benötigten Tabellen. Wir brauchen:
- LFA1 -> Lieferantenstammdaten
- BSAK -> Ausgeglichene Posten
- BSIK -> Offene Posten
- BSEG -> Belegsegment
- EKKO -> Einkaufsbelegkopf
Als nächstes erstellen wir wieder die Filter und benennen diese sprechend:
- LFA1_DE
- GJAHR
Der linke Bereich sieht dann aktuell so aus:
Stellen wir nun den Filter LFA1_DE ein und legen fest, auf welche Tabellen und Felder wir filtern wollen:
Type -> Fixed Value, da wir nur Lieferanten aus einem Land suchen und sich dieses Land nicht ändert
DataType -> String, da der Wert eine Zeichenkette ist
Condition -> Equal, da dieser Wert fix ist und nicht variieren kann
Values -> DE, Länderschlüssel für Deutschland
Table Relations -> LFA1 mit Feld LAND1, Tabelle und Feld, auf das der Filter gesetzt wird
Nun noch den zweiten Filter:
Type -> Fiscal Year
Condition -> Equal, da wir nur für die Geschäftsjahre suchen, die später im Task als Parameter übergeben werden
Table Relations -> BSAK und BSIK jeweils mit dem Feld GJAHR
Nachdem wir erfolgreich die Tabellen und die Filter erstellt haben, widmen wir uns nun den Repositories, die benötigt werden, um die Zwischenergebnisse zu speichern, mit denen wir dann weiterarbeiten können.
In diesem Beispiel haben wir den Feldnamen im Repository gleich dem Feldnamen in den Tabellen gesetzt. Die Auswirkung dessen siehst Du im nächsten Abschnitt.
Im ersten Schritt filtern wir die Tabelle LFA1 mit dem Filter LFA1_DE. Um diese Ergebnisse zu quasi zwischen zu speichern, erstellen wir das Repository LFA1_Kred_DE.
Für dieses Repository legen wir folgende Einstellungen fest:
- Fields
- LIFNR -> zur Speicherung der Lieferantennummern der deutschen Lieferanten
- Source-Tables
- LFA1 -> HIER haben wir jetzt zum ersten Mal kein C mehr daneben stehen, sondern ein A -> Das bedeutet: Das Package konnte automatisch die Felder verknüpfen, in diesem Fall die LIFNR (Lieferantennummer), da dieses Feld in der Tabelle LFA1 und in unserem Repository LFA1_Kred_DE gleich heißt.
- Target-Tables
- BSIK -> gleiche automatische Zuordnung der Felder über die LIFNR
- BSAK -> gleiche automatische Zuordnung der Felder über die LIFNR
Somit haben wir jetzt unser erstes Repository, dass alle Lieferantennummern deutscher Lieferanten beinhaltet.
Im nächsten Schritt wollen wir die Tabellen BSAK und BSIK filtern: wir wollen als Ergebnis die Belegnummern, einerseits gefiltert mit den gerade gefundenen Lieferantennummern und andererseits mit dem im Task eingegebenen Geschäftsjahr(en).
Dafür erstellen wir ein weiteres Repository mit den hier gefundenen Belegnummern und nennen es Belnr.
Jetzt müssen wir allerdings aufpassen: Hier nur die Belegnummern zu speichern, würde dazu führen, dass wir entweder nicht alle Belegnummern erhalten oder zahlreiche Doppeleinträge haben. Die Belegnummer kann sich nämlich in den Buchungskreisen und den Geschäftsjahren wiederholen. Um dem entgegen zu wirken, nehmen wir im Repository also nicht nur die Belegnummer mit auf, sondern auch zusätzlich das Geschäftsjahr und den Buchungskreis.
Da diese Informationen aus den Tabellen BSAK und BSIK kommen, geben wir diese beiden als Source-Tables an.
Und schon steht unser zweites Repository:
Doch warum steht jetzt auf der rechten Seite ein C, obwohl doch die Felder gleich heißen, wie in den Tabellen? Grund dafür ist, dass das automatische Mapping nur dann funktioniert, wenn auch auf die Groß-/Kleinschreibung geachtet wird. Da wir das Feld BuKrs und nicht BUKRS genannt haben, konnte das Feld nicht automatisch gemappt werden.
So, jetzt haben wir die Belegnummern von deutschen Lieferanten aus den gewünschten Geschäftsjahren in unserem Repository Belnr.
Nun suchen wir uns die Bestellnummern aus der Tabelle BSEG.
Das bedeutet, dass die BSEG in Abhängigkeit (Dependency) von unserem Repository Belnr gefiltert wird.
Durch die andere Schreibweise des Feldes für den Buchungskreis muss auch hier wieder das Custom Mapping durchgeführt werden.
Die hier gewonnenen Daten schreiben wir nun in das nächste und letzte Repository, dass wir EBELN nennen.
Da die Bestellnummern einmalig sind, benötigen wir hier nur ein Feld, dass ebenfalls EBELN genannt wird. Wir geben an, dass die hier gespeicherten Daten aus der Tabelle BSEG kommen (daher als Source-Table).
Und da wir hier nun auf die korrekte Groß-/Kleinschreibung geachtet haben, greift wieder das automatische Mapping.
Am Ende wollen wir die Tabelle EKKO mit den gefundenen Bestellnummern filtern, um alle weiteren Bestellkopf-Informationen zu erhalten. Wir binden nun also noch die EKKO ein. Da wir hier alle vorhandenen Informationen extrahieren möchten, markieren wir mit der Schaltfläche All nun alle Felder. Diese Tabelle wird wieder in Abhängigkeit (Dependency) des vorherigen Repositories EBELN gefiltert.
Und Et voilà! Schon haben wir am Ende alle Daten von relevanten Bestellkopfdaten aus gewünschten Geschäftsjahr(en) von deutschen Lieferanten.
Wenn wir uns zum Schluss noch die Elementübersicht in der Mitte ansehen, sieht das Ganze dann so aus:
Aktuell werden Dir folgende Ergebnistabellen ausgegeben:
- LFA1
- BSAK & BSIK
- BSEG
- EKKO
Interessieren Dich am Ende wirklich nur die ganzen Bestellkopfdaten, kannst Du die Tabellen LFA1, BSAK & BSIK sowie die BSEG auch in virtuelle Tabellen ändern. Diese werden dann nicht mehr als Ergebnistabellen am Ende gespeichert.
