Next Level Analytics, Teil 7

Autor: Axel Eggers | Veröffentlicht: 22.12.2020

 

Im 6.Teil der Serie haben wir einen Calculation View zur Berechnung von Beständen zu einem gewünschten Stichtag erstellt. Früher hatten wir bereits andere Views zur Berechnung verschiedener EK- und VK-Preise definiert. Jetzt wollen wir die einzelnen Komponenten der Lösung zusammenbringen und einen Calculation View zur Berechnung von bewerteten Materialbeständen erstellen! 

Auch für diesen neuen View benötigen wir wieder einen Input Parameter und auch dieser soll wieder den Vortag als Vorschlagswert berechnen:

Next Level Analytics 7 - 1

Abbildung 1 Input Parameter Stichtag

Wir erstellen eine neue Projektion und verwenden diesmal aber keine Datenbanktabelle aus einem aDSO, wie wir es bei den Preisen und Beständen immer getan haben. Diesmal verwenden wir in unserem neuen View einen bereits vorhandenen, anderen Calculation View!

NExt Level Analytics 7-2

Abbildung 2 Projektion Bestände

Wir erinnern uns an unsere bisherigen Views: Jeder von ihnen stellt seine Daten am Ende in Form einer Tabelle bereit, die wir uns ja bereits über die Datenvorschau angesehen hatten. Wie die einzelnen Spalten berechnet werden, bleibt uns verborgen, aber wir nutzen das Endergebnis für unsere weiteren Berechnungen.

Wir sehen also: Calculation Views lassen sich schachteln, so dass sich komplexe Berechnungen in mehrere Views aufteilen lassen. Diese Vorgehensweise verbessert nicht nur die Wartbarkeit der Lösung, sie erhöht auch die Verarbeitungsgeschwindigkeit, weil typischerweise viele einzelne Komponenten parallel verarbeitet werden können.

Wir übernehmen die meisten Spalten aus dem View für die Bestände in die Ausgabe unserer Projektion, aber obwohl wir einen neuen Input Parameter definiert haben, verwenden wir ihn an dieser Stelle noch nicht.

NExt Level 7-3

Abbildung 3 Ausgabe Projektion Bestände

Wir erstellen jetzt eine zweite Projektion, in der wir wiederum einen bereits vorhanden Calculation View verwenden, diesmal den für die Berechnung der Einkaufspreise. Wie und auf Basis welcher Daten diese Preise berechnet werden, braucht uns an dieser Stelle nicht zu interessieren. Die Funktionalität ist in dem View gekapselt. 

Wir übernehmen die für uns relevanten Spalten in die Projektion …

Abbildung 4 Projektion EK-Preise

…und erzeugen damit die Ausgabe dieser zweiten Projektion.

NExt Level 7-5

Abbildung 5 Ausgabe Projektion EK-Preise

Wir haben bis jetzt zwei Projektionen in unserem View eingefügt, aber wir wollen ja die Bestände des einen mit den EK-Preisen des anderen ausmultiplizieren, um zu unseren bewerteten Beständen zu kommen. Dazu brauchen einen neuen Knoten, der uns die Spalten mit EK-Preisen an die Datensätze mit den Beständen anfügt. Wir erreichen dies mit einem JOIN Knoten und verhindern eine willkürliche Zuordnung der Datensätze über die Definition der Join-Bedingung.

Abbildung 6 Join Bestand mit EK-Preisen

In der Abbildung sehen wir, dass beide Projektionen, also Tabellen, über die Spalten Material, Lieferant, Währung und Mengeneinheit verknüpft wurden. Dabei spielen die unterschiedlichen technischen Namen der Spalten keine Rolle, wichtig sind nur die inhaltliche Übereinstimmung (Semantik: MATERIAL = MATNR) und gleiche bzw. kompatible Datentypen. 

Die Symbolik der Verbindungslinien steht für einen LEFT OUTER JOIN. Das bedeutet, dass zu jedem Datensatz aus der linken Tabelle versucht wird, einen oder mehrere Datensätze aus der rechten Tabelle zu finden und dadurch die Zeilen und Spalten der Ergebnismenge zu ergänzen. In der Modellierung können wir dem System bereits mitgeben, wie viele Datensätze wir jeweils zu einem Satz erwarten: die Kardinalität des Joins. In unserem Fall handelt es sich eine N:1 Beziehung: Zu jedem Bestand erwarten wir einen EK-Preis, aber ein EK-Preis kann für viele Bestände (z.B. in verschiedenen Werken für das gleiche Material) verwendet werden. 

Bei einem LEFT OUTER JOIN rechnen wir bereits damit, dass möglicherweise nicht zu jedem Datensatz der linken Tabelle auch tatsächlich ein passender Satz aus der rechten Tabelle gefunden werden kann. In solchen Fällen sind die Werte dieser Spalten im Ergebnisdatensatz NULL, also undefiniert. 

Der präzisen Definition von Join-Bedingungen und deren Kardinalitäten sollten wir immer sehr große Bedeutung beimessen: durch falsche oder ungenaue Definitionen können wir entweder zu viele oder aber auch zu wenige Datensätze in unserer Ergebnismenge erhalten. Dadurch bekommen wir dann natürlich falsche Ergebnisse. 

Nach diesem kurzen Abstecher in die Welt der Join Definitionen widmen wir uns jetzt wieder unserer Bestandsbewertung: in der Ausgabe unseres Join Knotens stehen uns jetzt sowohl die Bestandsmengen als auch die EK-Preise zur Verfügung.

 

Next Level 7-7

Abbildung 7 Ausgabe Join Bestand mit EK-Preisen

Aus den Komponenten Menge und Preis können wir jetzt einen Wert berechnen. Dazu definieren wir auf dem Join Knoten Calculated Columns mit dem passenden Datentyp. 

Da wir drei unterschiedliche Bestandsmengen und auch drei verschiedene EK-Preise haben, erstellen wir insgesamt neun Calculated Columns.

Next Level 7-8

Abbildung 8 Beispiel Bestandswert zum EK-Preis

Jetzt haben wir unsere Bestände immerhin schon mit EK-Preisen bewertet, wollen diese aber noch um Verkaufspreise erweitern. Dazu erstellen wir wieder einen neuen Projektions-Knoten und benutzen den bereits vorhandenen Calculation View für die Berechnung der VK-Preise.

NExt Level 7-9

Abbildung 9 Projektion VK-Preise

Aus den verfügbaren Spalten wählen wir wieder die für uns relevanten aus und definieren damit den Ausgabebereich für diesen Knoten.

Next Level 7-10

Abbildung 10 Ausgabe Projektion VK-Preise

Jetzt stehen wir wieder vor der Frage, wie wir unsere bisher verfügbaren Datensätze um die VK-Preisinformationen ergänzen können. Die Lösung ist auch hier wieder ein LEFT OUTER JOIN, denn wir können nicht ausschließen, dass uns evtl. einige VK-Preise fehlen. Wie schon gesagt, wenn es keinen passenden Datensatz in der rechten Tabelle vom Join gibt, erhalten diese Spalten in der Ergebnismenge den Wert NULL.

Abbildung 11 Join Bestand mit EK- + VK-Preisen

In diesem Join Knoten haben wir zwar eine etwas andere Liste von verknüpften Merkmalen, aber wir definieren auch hier wieder eine Kardinalität von N:1. 

Im Ausgabebereich stehen uns jetzt also die Mengen, die EK- und VK-Preise zur Verfügung, …

Next Level 7- 12

Abbildung 12 Ausgabe Join Bestand mit EK- + VK-Preisen

… so dass wir jetzt wieder über Calculated Columns einen zum VK-Preis bewerten Bestand ausrechnen können. Da wir unsere drei verschiedenen Mengen mit vier verschiedenen VK-Preisen bewerten können, erhalten wir also insgesamt zwölf VK-Preis bewerte Bestände.

Next Level 7-13

Abbildung 13 Beispiel Bestandswert zum VK-Preis

Zu guter Letzt wiederholen wir diese Schritte noch einmal für die werkspezifischen VK-Preise: Neue Projektion mit dem vorhanden Calculation View für diese VK-Preise, …

Next Level 7-14

Abbildung 14 Projektion werkspezifische VK-Preise

… Ausgabebereich mit den für uns relevanten Spalten, …

Next Level7-15

Abbildung 15 Ausgabe Projektion werkspezifische VK-Preise

ein neuer LEFT OUTER JOIN ergänzt die zusätzlichen Preise an unsere bisher verfügbaren Daten …

Next Level 7-16

Abbildung 16 Join Bestand mit EK-, VK- + VKP-Preisen

… wir erhalten einen um diese VK-Preise erweiterten Ausgabebereich …

Abbildung 17 Ausgabe Join Bestand mit EK-, VK- + VKP-Preisen

… und können mit weiteren Calculated Columns wiederum neue bewerte Bestände berechnen

Abbildung 18 Beispiel Bestandswert zum werkspezifischen VK-Preis

Diesen letzten Join Knoten können wir jetzt mit der Aggregation verbinden und erhalten eine sehr lange Liste an verfügbaren Spalten, die wir alle in die Aggregation übernehmen.

Next Level7 -19

Abbildung 19 Aggregation bewerteter Bestand

In der folgenden Abbildung sehen wir noch einmal das gesamte Szenario: zu den Datensätzen aus dem View für die Berechnung der Bestandsmengen verknüpfen wir nacheinander die EK- und VK-Preise. Durch jeden JOIN Knoten verbreitern wir unseren ursprünglichen Datensatz zunächst um die Preise und dann noch einmal um die berechneten Bestandswerte.

Abbildung 20 Szenario bewerteter Bestand

Wir hatten uns jedes Mal für einen LEFT OUTER JOIN entschieden, weil wir damit rechnen, auch einmal keinen Preis zu finden. Was würde eigentlich passieren, wenn wir statt dessen einen INNER JOIN modellieren würden? Wie verändert sich unsere Ergebnismenge? 

Wir riskieren damit, dass wir weniger Datensätze im Ergebnis vorfinden! Ein INNER JOIN liefert immer dann einen Ergebnisdatensatz, wenn sowohl in der linken als auch in der rechten Tabelle ein passender Datensatz vorhanden ist. Fehlt auf einer Seite das Gegenstück, gibt es keinen Ergebnisdatensatz! 

Zum Schluss kommen wir noch einmal auf die Input Parameter zurück. Eine grundlegende Anforderung an unseren Calculation View besteht ja darin, die bewerteten Bestände zu einem Stichtag zu berechnen. Daraus folgt, dass wir sowohl die Bestandsmengen als auch die Preise zu diesem Stichtag berechnen müssen. Sie erinnern sich aber, dass wir in diesem View zwar mehrere Projektionen eingebaut, diese aber noch nicht auf unseren Stichtag eingeschränkt haben. 

Als Anwender dieses Views möchte ich den Stichtag natürlich nur ein einziges Mal eingeben müssen. Nicht für jede beteiligte Komponente! 

Wir erreichen dies, indem wir den Input Parameter an die beteiligten Views („nach unten“) weiterleiten. Dabei ist dann der technische Name des Parameters nicht weiter relevant, nur die verwendeten Datentypen unserer Parameter müssen kompatibel zueinander sein.

Abbildung 21 Input Parameter weiterleiten

Nun ist unser Calculation View zur Berechnung bewerteter Bestände zu einem Stichtag fertig! Schauen wir uns noch die Daten für einen Artikel an, wobei wir zunächst die spezifischen Calculation Views zur Berechnung der Preise benutzen. Jede Datenvorschau sollten wir natürlich mit dem gleichen Stichtag aufrufen.

Übersicht EK-Preise

Abbildung 22 Beispiel mit EK-Preisen

Übersicht VK-Preise

Next Level 7 23

Abbildung 23 Beispiel mit VK-Preisen

Übersicht werkspezifische VK-Preise

Next Level 7 24

Abbildung 24 Beispiel mit werkspezifischen VK-Preisen

EK-Preis bewertete Bestände

Abbildung 25 Beispiel mit EK-Preisen bewertete Bestände

Wir erkennen den ZNNE und ZRKP-Preis für das Material bei diesem Lieferanten aus Abbildung 22 wieder, so dass die Mengen in den verschiedenen Werken bewertet werden können. 

VK-Preis bewertete Bestände

NExt Leven 7 -26

Abbildung 26 Beispiel mit VK-Preisen bewertete Bestände

Hier erkennen wir den ZVKP-Preis für das Material in diesem Vertriebsweg aus Abbildung 23 wieder, so wiederum alle Mengen in den Werken bewertet werden können.

NExt Leven 7 -27

Abbildung 27 Beispiel mit werkspezifischen VK-Preisen bewertete Bestände

An diesen Daten erkennen wir sehr schön die Arbeitsweise von einem LEFT OUTER JOIN: Während für das Material in einigen Werken (z.B.: 3060) ein Preis gepflegt ist, gibt es andere Werke ohne Preiszuordnung (z.B.: 3066). Dennoch sehen wir einen Datensatz in der Ergebnismenge für genau diese Kombination! Bei der Verwendung eines INNER JOIN würden diese Daten fehlen! 

Als Wert für die Preise und Werte sehen wir bei den fehlenden Zuordnungen NULL. Außerdem sehen wir das Ergebnis einer Multiplikation mit NULL: es ist NULL. 

Für die letzte Ansicht beschränken wir uns auf eine kleine Liste von Werken.

Next Level 7- 28

Abbildung 28 Beispiel mit EK- + VK-Preisen bewertete Bestände

Wenn wir jetzt das Werk aus der Anzeige entfernen, die Daten also verdichten, erhalten wir die Summe der Bestände über die Werke.

NExt Level 7 - 29

Abbildung 29 Beispiel mit Verdichtung Bestandswerte

Zurück zum Analytics-Blog

Der Blog hat Ihnen gefallen und Sie wollen gerne direkt per E-Mail benachrichtigt werden, wenn der nächste Artikel erscheint? Gerne geben wir Ihnen Bescheid!

Ansprechpartner SAP Analytics Blog Sascha Hanf

Haben Sie Fragen?

Sascha Hanf ist Ihr Ansprechpartner für den Analytics Blog.

Jetzt Kontakt aufnehmen
Ansprechpartner SAP Analytics Blog Sascha Hanf

Haben Sie Fragen?

Sascha Hanf ist Ihr Ansprechpartner für den Analytics Blog.

Jetzt Kontakt aufnehmen