Berechnungen mit Envision - Software zur Bestandsoptimierung

Berechnungen












Startseite » Ressourcen » Hier

Mit Envision haben Sie die Möglichkeit, praktisch alle Berechnungen auszuführen, die auch mit Excel gemacht werden könnten. Diesbezüglich ist auch die Syntax zur Ausführung solcher Berechnungen ähnlich zu der, die in Excel-Formeln benutzt wird. Lokad richtet ein besonderes Augenmerk auf Vektorberechnungen. Vektoroperationen werden zur gleichzeitigen Verarbeitung mehrerer Daten, anstatt der Verarbeitung von einem Wert nach dem anderen, benutzt. Auf dieser Seite werden Tabellen und Vektoren ausführlich erklärt, was Ihnen bei der Erstellung Ihrer eigenen Berechnungen mit Envision helfen sollte.

Um diese Seite besser verstehen zu können, raten wir Ihnen, das Beispielsdataset einzurichten. Die Fähigkeiten von Envision für den Upload der Eingabedateien haben wir noch nicht beschrieben, doch mit unseren Beispielen sehen Sie die Linien, die Sie am Anfang Ihres Skripts einfügen müssen.

Tabellen und Vektoren

Envisions Datenmodell dreht sich um Tabellen und Vektoren. Eine Envision-Tabelle ist sehr ähnlich zu denen, die in relationalen Datenbanken vorkommen. Aus einer Excel-Perspektive ist eine Tabelle ein gut geformtes Arbeitsblatt, dessen erste Zeile Spaltenüberschriften enthält und dessen (viele) Zeilen darunter Daten enthalten, die korrekt mit diesen Spaltenüberschriften übereinstimmen. In einem Envision-Skript sind die Tabellen auch benannt und die Namen der Tabellen hängen gewöhnlich mit den tabellarischen Dateien, auf denen sie basieren, zusammen. Vektoren beziehen sich auf die Spalten der Tabelle und werden ähnlich benannt. Envision nutzt den Begriff „Vektor“ statt „Spalte“, um hervorzuheben, dass die Berechnungen in allen Vektorwerten gleichzeitig ausgeführt werden können, also in allen Zeilen der ursprünglichen Tabelle.

Lassen Sie uns dies anhand von einigen Zeilen Skript, die auf das Beispiel-Dataset angewandt werden können, veranschaulichen. Hierunter berechnen wir für jeden Bestellposten den Steuersatz. In anderen Wörtern, die Rate zwischen dem Steuerbetrag und dem Betrag abzüglich Steuer, der dem Kunden in Rechnung gestellt wird.
read "/sample/Lokad_Items.tsv"
read "/sample/Lokad_Orders.tsv" as O
read "/sample/Lokad_PurchaseOrders.tsv" as PO
O.TaxRate = O.TaxAmount / O.NetAmount
Hier bezieht sich O auf die Tabelle der Bestellungen, die die gesamten historischen Umsatzdaten enthält, in der jede Transaktion mit so vielen Zeilen, wie Artikel in dieser Transaktion vorkommen, dargestellt wird. Die Variable O.TaxAmount auf den Vektor, der mit der Spalte TaxAmount in der Tabelle O assoziiert ist. Bezüglich der Syntax können Sie sich merken, dass ein Punkt (.) zwischen dem Namen der Tabelle und dem Namen des Vektors steht, da dieses Muster häufig in Envision benutzt wird.

Operationen die ein Gleichheitszeichen = beinhalten werden Zuweisungen (assignments) genannt: Die Berechnung findet auf der rechten Seite des Zeichens = statt und das Ergebnis wird der linken Seite der Anweisung zugeordnet. Im oberen Beispiel findet eine Division auf der rechten Seite statt. Da weder O.TaxAmount noch O.NetAmount in diesem Skript definiert sind, versucht Envision, die Daten direkt aus dem Eingabe-Dataset zu laden. Da die Tabelle O des Datasets beide Spalten NetAmount und TaxAmount beinhaltet, wird das Skript erfolgreich ausgeführt. Auf der linken Seite haben wir O.TaxRate, das dem soeben berechneten Steuersatz zugewiesen wird. Eine Zuweisung entspricht der Logik, eine neue Spalte in Excel zu erstellen, die so wie die Variable der Zuweisung, also TaxRate in diesem Fall, benannt wird.

In den folgenden Skript-Snippets lassen wir der Kürze halber die Zeilen read “/sample/Lokad_XYZ.tsv” aus allen Beispielen weg, da dieser in jedem Skript ganz oben stehen muss.

Die Syntax der Berechnung ist in Envision ähnlich zu der, die in Excel-Formeln benutzt wird. Im unteren Skript führen wir eine Reihe (verschiedenster) Berechnungen aus, um die Syntax darzustellen.
O.A = 42
O.B = 5 * (1 + O.A)
O.C = (O.A + O.B) * (1 + O.A)
Hier definiert das Skript drei Vektoren, die entsprechend als A, B und C benannt wurden. Alle drei Vektoren sind von der Tabelle O abhängig. Die erste Zeile stellt eine einfache Zuweisung dar, in der der Wert 42 an O.A zugewiesen wird. Doch da O.A ein Vektor ist, ist es nicht nur der Wert 42, sondern ein Wert für jede Zeile der ursprünglichen Tabelle. Envision setzt ein besonderes Augenmerk auf Vektoren und die meisten Operationen mit Vektoren werden gleichzeitig auf alle Werte ausgeführt.

O ist auch nicht die einzige verfügbare Tabelle im Beispiel-Dataset. So enthält das Beispiel-Dataset auch die Tabelle PO, in der sehr ähnliche Operationen ausgeführt werden können.
PO.A = 42
PO.B = 5 * (1 + PO.A)
PO.C = PO.A + PO.B
Da wir soeben eine zweite Tabelle vorgestellt haben, entsteht die Frage, ob Envision auch Operationen zwischen den Tabellen ausführen kann. Die Antwort darauf ist ja, doch hierfür benötigen wir etwas mehr. Sehen wir uns folgendes Skript an:
O.A = 1
PO.A = O.A + 1 // FALSCH!
Da die Tabellen O und PO aus keinem Grund ähnlich gestaltet sind - beide Tabellen enthalten nicht einmal dieselbe Anzahl von Zeilen - wäre die Semantik, die mit einer solchen Operation einhergeht, äußerst unklar. Daher ist so eine Operation in Envision nicht zulässig. Beim Versuch, ein solches Skript auszuführen, schlägt dieses Fehl und es wird eine Fehlermeldung angezeigt.

Doch Envision bietet sehr vielfältige Arten, Daten aus verschiedenen Tabellen zu kombinieren, was im nächsten Teil erklärt wird.

Besondere „Artikeltabellen“

Die von Envision genutzten Tabellen werden benannt. Doch für diese Konvention besteht eine Ausnahme, nämlich die Artikeltabelle. Im Handel kann man erkennen, dass eine Tabelle für ein Großteil der Berechnungen unter den anderen hervorsticht: die Liste von Produkten / Varianten / SKUs / ..., je nach Unternehmenssparte. Im Gegensatz zu beispielsweise einer relationalen Datenbank, in der alle Tabellen gleich behandelt werden, wird die Artikeltabelle von Envision besonders behandelt, was den Umgang mit den verschiedenen Szenarien im Handel vereinfacht.

Im Laufe der Zeit erstellt jeder Einzelhändler, unabhängig von seiner Größe, eine Tabelle, in der alle Produkte aufgelistet sind. Gewöhnlich steht ein Produkt pro Zeile und die Tabelle beinhaltet auch viele weitere Spalten, um zusätzliche Information einzutragen, wie statische Information, beispielsweise Produktkategorie, oder dynamische Information, wie die Gesamtumsätze der letzten 5 Wochen. Je nachdem, wie die Lage ist, werden die Zeilen mit Produkten, SKUs oder ähnlichen detaillierten Darstellungen der Produkte, die verkauft werden, assoziiert. Eine solche konsolidierte Tabelle ist in vielen Fällen sehr praktisch: zur Feststellung von totem Bestand, Aktualisierung von Preisen, Erkennung der meistverkauften Produkte, usw. Wenn Sie im Einzehandel tätig sind, haben Sie sich sicherlich schon öfters mit solchen Tabellen beschäftigt.

Bei Lokad haben wir verstanden, dass solche Tabellen im Einzelhandel universell vorkommen und haben daher beschlossen, diese auch in unsere Technologie einzubauen. Wir entwickelten Envision nach diesem Muster, so dass wir so nahe wie möglich an der gewöhnlichen Praxis im Handel dranbleiben konnten.

Sehen wir uns noch einmal das Beispiel-Dataset an. Dieses enthält eine Liste von Artikel. Gehen wir davon aus, dass wir den Bestandswert von jedem Artikel berechnen wollen. Wenn die „Artikeltabelle“ Items hieße, könnte man dies so tun:
Items.Stock = Items.StockOnHand + Items.StockOnOrder
Items.StockValue = Items.TotalStock * BuyPrice
Doch nur für die „Artikeltabelle“ kann der Name weggelassen werden. Daher sollte das Skript so geschrieben werden:
Stock = StockOnHand + StockOnOrder
StockValue = Stock * BuyPrice
Das Präfix Items. wurde entfernt und, der Konvention nach, bezieht sich eine Variable, dessen Namen keinen Punkt (.) enthält, auf einen Vektor, der mit der „Artikeltabelle“ assoziiert ist. Da Berechnungen bezüglich der „Artikel“ im Handel so üblich sind, macht diese Konvention Envision in der Praxis viel lesbarer.

Eines der Hauptgründe für den Erfolg von „Artikeltabellen“ ist, dass die meisten historischen Daten im Handel sehr praktisch als eine Liste von Ereignissen dargestellt werden können, in der jedes Ereignis einem Artikel zugeordnet wird. So werden beispielsweise die historischen Umsatzdaten - mit mindestens - einer Tabelle mit drei Spalten dargestellt: die Artikelidentifikation, das Datum und die gekaufte Menge. Ähnlich können auch die historischen Einkaufsdaten mit denselben drei Spalten und idealerweise auch noch dem Lieferdatum, zur Berechnung der Durchlaufzeit zwischen Bestellung und Lieferung, ergänzt werden. Auch die Rückgaben von Kunden können als Tabelle dargestellt werden, die Spalten für Artikelidentifikation, Datum, Menge und idealerweise Kundenidentifikation, falls man das Verhalten wiederkehrender Kunden analysieren möchte, enthalten.

Und die Liste lässt sich weiterführen. Im Handel geht es immer um Ströme: Warenströme von Lieferanten zu Kunden; Geldströme von Kunden an Lieferanten. All diese Ströme können in kleinere Grundzeilen geteilt werden, wobei jede Zeile einem bestimmten Artikel zugeordnet wird. Daher betrachtet man im Handel nicht alle Arten von Tabellen, sondern Tabellen, die hauptsächlich auf Artikel ausgerichtet sind. Genau dieses Muster möchte Envision festhalten.

Die „Artikeltabelle“ hat nur eine Pflichtspalte: Die Spalte der Artikelidentifikation, die „Id“ genannt werden sollte, was die Envision-Konvention betrifft. Fast alle anderen Tabellen, die auf Envision hochgeladen werden, müssen auch eine eigene „Id“ Spalte enthalten. Oben haben wir gesehen, dass es nicht möglich ist, die Tabelle O und die PO zu kombinieren, da diese Tabellen nicht gleich gestaltet sind. Und genau die Spalte Id, die sowohl in der „Artikeltabelle“ als auch in fast allen anderen Tabellen vorkommt, bildet die notwendige „Brücke“, um die Kombination zu ermöglichen.

Lassen Sie uns das anhand einer Kapitalflussrechnung veranschaulichen. Gehen wir davon aus, dass man für jeden Artikel die Einzahlung bezüglich der historischen Verkaufsdaten und die Auszahlung bezüglich der historischen Kaufdaten berechnen möchte. Dies kann mit folgendem Skript getan werden.
CashIn = sum(O.NetAmount)
CashOut = sum(PO.NetAmount) 
CashFlow = CashIn - CashOut
Hier können wir sehen, dass die „Artikel“ auf der linken Seite der Zuweisung stehen und die anderen Tabellen an der rechten Seite stehen, zumindest in Zeilen 1 und 2. Es ist zulässig, mehrere Tabellen gleichzeitig zu nutzen. Dies ist dem Aggregator sum() zu verdanken. Wir werden in diesem Dokument nicht näher auf den Aggregator eingehen, doch es reicht zu sagen, dass, wie der Name schon sagt, der sum() Aggregator die Summer aller NetAmount für jeden Artikel berechnet. Die Abfrage zwischen Artikel und Bestellungen wird auch transparent ausgeführt, da die Tabelle O auch eine Spalte Id beinhaltet.

Zum besseren Verständnis haben wir die Berechnung auf drei Zeilen geteilt. Doch das Skript kann kompakter geschrieben werden, ohne die Zwischenvariablen zu nennen, wie folgt:
CashFlow = sum(O.NetAmount) - sum(PO.NetAmount)
Zusätzlich zur Addition, unterstützt Envision alle klassischen Aggregatoren: Durchschnitt, Min, Max, Median ... Diese Aggregatoren bieten viele Möglichkeiten, die Artikeltabelle mit deskriptiven Attributen zu ergänzen, was für die Lösung von handelsüblichen Problemen äußerst nützlich sein kann. Obwohl Sie einen neuen Vektor unter den „Artikeln“ erstellen können, indem Sie eine andere Tabelle und einen Aggregator nutzen, ist es auch andersrum möglich, einen Vektor aus der „Artikeltabelle“ zu nutzen, wenn eine Berechnung, die mit einer anderen Tabelle zusammenhängt, ausgeführt wird.

Gehen wir davon aus, dass wir die VAT (Umsatzsteuer), die mit jedem Bestellposten zusammenhängt, erneut berechnen wollen. Um dies zu vereinfachen, wählen wir einen Umsatzsteuersatz von 20% für alle Artikel der gesamten historischen Daten. Dies könnte, wie folgt, geschrieben werden:
VatRate = 0.2 // hypothesis
F = VatRate / (1 - VatRate)
O.Vat = O.NetAmount * F
Der Vektor VatRate erweitert natürlich auf einen Vektor, der wie die Tabelle O gestaltet ist, da jeder Bestellposten mit einem einzigen Artikel verbunden ist. Diese Erweiterung kann durch den Code verdeutlicht werden:
VatRate = 0.2 // hypothesis
O.VatRate = VatRate
O.F = O.VatRate / (1 - O.VatRate)
O.Vat = O.NetAmount * O.F
In den oberen Beispielen werden die Vektoren F lediglich zur Veranschaulichung der Aufschlüsselung der Berechnung eingeführt.

Sie können sich am Rande merken, dass es möglich ist, in Envision beliebige Tabellen zu laden, auch wenn diese Tabellen keine Id Spalte besitzen. Doch solche erweiterte Szenarien gehen über das Ziel des vorliegenden Dokuments hinaus.

Besonderer Status für das Datum

Die Artikelliste ist ein besonderer Fall für Envision, da sich, wie wir sehen konnten, viele grundlegende Operationen im Handel um die Artikel drehen. Doch diese Operationen sind auch gewöhnlich mit einem bestimmten Datum verbunden. In jeder Zeile der historischen Umsatzdaten ist auch ein anwendbares Datum vorhanden. Dasselbe gilt auch für die historischen Einkaufdaten und für fast alle Daten, die als historische Daten verstanden werden können. Wegen der großen Bedeutung der historischen Daten für den Handel, in dem praktisch alle Unternehmensoperationen in einer Liste beschrieben werden können, die Einträge nach Datum für Bestandsbewegungen oder Zahlungen enthält, legt Envision ein besonderes Augenmerk auf das Datum, wie im Handel üblich ist.

Alle Tabellen können eine Spalte Date zusätzlich zur kanonische Spalte Id enthalten. Wenn eine Date Spalte vorhanden ist, wird die Tabelle sowohl nach Artikelidentifikation als auch nach Datum indexiert. Die Indexierung nach Datum ist oft sehr praktischen, wenn man einen bestimmtem Zeitraum auf eine Berechnung anwenden möchte. So werden die gesamten historischen Daten unabhängig von der Art der Eingaben ähnlich gefiltert.

Um dies zu veranschaulichen, gehen wir zu unserer Kapitalflussrechnung zurück. Wenn wir davon ausgehen, dass wir statt Werte für die gesamten historischen Daten, den Kapitalfluss pro Artikel berechnen möchten, unter ausschließlicher Berücksichtigung der Daten des letzten Jahres, könnten wir dies, wie folgt, tun:
end := max(date)
when date > end - 365
  CashFlow = sum(O.NetAmount) - sum(PO.NetAmount)
Die Variable end wird als das aktuellste Datum definiert, das im gesamten Eingabe-Dataset vorhanden ist, bezieht. Da es sich bei end um ein Datum handelt, erkennt man, dass Envision die Möglichkeit bietet, Datumsarithmetik auszuführen, wie im oberen Skript gezeigt wird. Über die Konvention ein +1 einem Datum in Envision hinzuzufügen, wird dem bestimmten Datum ein Tag hinzugefügt. So kann man, wenn man 365 Tage subtrahiert, ca. ein Jahr zurückgehen.

Das Skript beginnt mit einem when Filter, der eine Bedingung zur Verarbeitung aller Zeilen in einem bestimmten Block des Skripts darstellt. Was die Artikel betrifft, sind diese nicht nach Datum indexiert. Daher hat der Datumsfilter keinen Einfluss auf sie und sie erscheinen weiterhin im when Block. Doch sowohl die Bestellungen als auch die Aufträge besitzen eine eigene Date Spalte. Daher werden alle Zeilen, die die Bedingung des when Filters nicht erfüllen, aus dem Block des Skripts gefiltert.

Demzufolge verarbeitet der sum() Aggregator nur die nicht gefilterten Zeilen im when Block, d.h. die Zeilen, die weniger als ein Jahr alt sind. Dieselbe Berechnung wurde hier mit Zwischenvariablen ausgeführt, wie anfänglich auch mit den gesamten historischen Daten.
end := max(date)
when date > end - 365
  CashIn = sum(O.NetAmount)
  CashOut = sum(PO.NetAmount)
  CashFlow = CashIn - CashOut
Mit dem oberen Beispiel wird wahrscheinlich etwas deutlicher, warum die when Anweisung zu Beginn des Filterungsblocks genutzt wird. Tatsächlich werden alle Zeilen im Block demselben Datenfilter unterzogen, was man an den zusätzlichen Leerzeichen am Anfang der Zeilen 2, 3 und 4 erkennt.

An diesem Skript wird auch die Fähigkeit Envisions deutlich, komplexe Daten aus anderen Tabellen, mit der „Artikeltabelle“ erneut auszurichten. Aus der Perspektive von Excel, ist so, als würde man andere Blätter (z.B. die Bestelldaten) mit Hilfe eines Masterblatts, das die Produktliste enthält, in Spalten umwandeln könnte. Envision macht diesen Prozess viel einfacher.