Dateien mit Envision lesen - Software zur Bestandsoptimierung

Tabellarische Dateien mit Envision lesen












Starseite » Ressourcen » Hier

Envision lädt und verarbeitet tabellarische Dateien, die in Ihrem Lokad-Konto gespeichert sind. Außerdem bietet Lokad native Unterstützung von einer Reihe Apps dritter Parteien. Wird Ihre App von Lokad unterstützt, übernehmen wir intern den kompletten Datenimport und die Erstellung der notwendigen Dateien. Sollte dies nicht der Fall sein, oder kann Lokad nicht alle relevanten Daten erhalten, ist es möglich, Dateien manuell in Lokad zu importieren. Auf dieser Seite erklären wir Ihnen, wie diese tabellarischen Dateien zur Kompatibilität mit Envision formatiert sein sollten. Auch die Syntax, mit der das System die Dateien liest, ist unten dokumentiert.


In Kürze

Die von Lokad unterstützten Dateiformate sind:

  • CSV, TSV und andere ähnliche und gängige Dateien als flacher Text, .csv- oder .tsv- oder .txt-Dateien.
  • Microsoft Excel 2007+ Dateien, .xlsx-Dateien.
  • GZip-Archiv, .gz-Dateien; der Inhalt muss eine Flatfile sein.
  • WinZip-Archiv, .zip-Dateien; der Inhalt muss eine Flatfile sein; das Archiv sollte genau 1 Datei enthalten.
  • 7z-Archiv, .7z-Dateien; der Inhalt muss eine Flatfile sein; das Archiv sollte genau 1 Datei enthalten.

Die Syntax, um in Envision Dateien zu lesen ist:
read "/foo/myorders.csv.gz" as Orders with "My Id" as Id, Quantity : number
read "/foo/promos*.xlsx" as Promos[*] // Platzhalter '*' hier, es werden mehrere Dateien gelesen
read max "/foo/stocks*.xlsx" as Stocks[*] // max within the wildcard '*', es wird nur eine Datei gelesen
read "/foo/backorders.tsv.zip" unsafe as Backorders[Date, *] // 'unsafe' Parsing-Schwierigkeiten tolerieren

Eine Dateiablage mit Konnektoren

Jedes Lokad-Konto verfügt auch über einen eigene Dateiablage. Vereinfacht bedeutet dies, dass es möglich ist, Ordner zu erstellen und Dateien in diese Ordner hochzuladen. So bietet Lokad einen ähnlichen Dienst, wie andere File-Hosting-Dienste wie etwa Box oder Dropbox, nur dass die meisten Features, um Dateien zu teilen, nicht vorhanden sind. Das Ziel Lokads ist auch nicht eine weitere App für File-Sharing zur Verfügung zu stellen, sondern einen komplett transparenten zum Zugang zu allen Daten zu haben, die von Lokad bei der Analyse Ihres Unternehmens genutzt werden. So liegen die entsprechenden Daten, immer wenn eine Prognose oder ein Dashboard von Lokad erstellt wird, in Ihrem Konto als Dateien vor, die heruntergeladen und auch unabhängig von Lokad analysiert werden können.

Für kleinere Unternehmen kann es eine mühsame Aufgabe sein, alle relevanten historischen Daten des Betriebs in Dateien zu erfassen, da ihnen überhaupt ausreichende IT-Ressourcen fehlen. Daher stellt Lokad für viele der gängigen Unternehmensapps - Brightpearl, Linnworks, QuickBooks, TradeGecko, Unleashed, Vend, ... um einige Beispiele zu nennen - eingebaute Konnektoren. Diese Konnektoren können mit der App verbunden werden, gewöhnlich über eine online API (Programmierschnittstelle) und erstellen im Lokad-Konto Dateien, die direkt so formatiert werden, dass sie für die Verarbeitung von Envision genutzt werden können.

Wird Ihre Unternehmensapp nicht unterstützt (sollte dies der Fall Sein , da wir die am meisten angefragten Apps gewöhnlich unterstützen) oder wenn Lokads eingebaute Unterstützung nicht alle relevanten Daten deckt, ist es möglich, die Dateien direkt auf Lokad zu laden, da wir auch manuelle Uploads über die Webseite anbieten. Da aber Daten regelmäßig aktualisieren müssen, ist es viel praktischer, wenn die Datenübertragung komplett automatisch durchgeführt werden kann. Daher unterstützt Lokad auch Protokolle wie FTP und SFTP, die eine automatische Datenübertragung ermöglichen.

Breite Unterstützung von tabellarischen Dateien

Lokad unterstützt eine ganze Reihe verschiedener Formate, die tabellarische Daten enthalten. Wir unterstützen beliebte Formate wie Excel-Blätter oder CSV-Dateien (comma-separated value). Wenn Sie mit dem Import/Export von Flatfiles bereits Erfahrung haben, wissen Sie wahrscheinlich, dass tausende kleine technische Details den Prozess erschweren können:

  • Die Codierung der Datei kann von der von der App erwarteten Codierung abweichen.
  • Datum oder Zahlen sind nicht, wie erwartet, formatiert.
  • Auch die Codierung vom Trennzeichen der Spalte oder Zeilenumbruch kann abweichen.

Unser System wurde mit der Fähigkeit entwickelt, technische Details, wie etwa die Codierung, Format von Datum und Zahlen, Trennzeichen, usw. automatisch zu erkennen. Obwohl alles automatisch läuft, ist der Prozess, der bei Lokad beim Lesen der Dateien im Hintergrund läuft, gar nicht so simpel. Zum Beispiel unterstützen wir zurzeit die automatische Erkennung über 100 verschiedener Formate für das Datum.

In der Praxis sind die Richtlinien für das Format der tabellarischen Dateien einfach: Die Spaltenüberschriften sollte in der ersten Zeile der Datei stehen (dies ist auch in Excel-Blättern erforderlich) und man muss sich vergewissern, dass die Tokenwerte sich nicht mit den Trennzeichen überschneiden, wenn man flache Textdateien, wie CSV oder TSV nutzt.

Bei wachsender Größe der Flachdateien kann es auch praktischer werden, die Dateien vor dem Upload zu komprimieren. Lokad unterstützt dabei flache Textdateien, die mit GZip komprimiert wurden, solange eine .gz-Dateiendung vorhanden ist. So wird beispielsweise Lokad_Items.tsv.gz als TSV-Datei erkannt, die mit GZip komprimiert wurde. Dieses Muster funktioniert auch mit der .zip-Erweiterung für WinZip-Archive und für die .7z-Erweiterung für 7z-Archive. Im Falle von WinZip und 7z sollte das Archiv nur eine einzige komprimierte Datei enthalten, denn Envision unterstützt keine Archive mit mehreren Dateien. Da Excel-Dateien bereits komprimiert sind, ist es nicht notwendig, sie zu komprimieren, auch wenn sie sehr groß sind.

Richtlinien zur Benennung von Dateien und Spalten

Lokad kann praktisch mit fast allen Dateien- und Spaltennamen auskommen. Doch wenn bestimmte Richtlinien eingehalten werden, kann das Envision-Skript viel einfacher gestaltet werden. Das Beispiel-Dataset ist ein gutes Beispiel für ein Set von Dateien, das diese Richtlinien berücksichtigt. Sollten Sie bisher noch nicht die Gelegenheit gehabt haben, sich diese Dataset anzusehen, empfehlen wir Ihnen, dies jetzt zu tun.

Es wird erwartet, dass Dateien nach diesem Muster benannt werden: in Lokad_TableName.xyz wird der TableName durch den Namen der Tabelle ersetzt und xyz wird durch die Dateiendung ersetzt, zum Beispiel xlsx für Excel-Blätter. Der Tabellenname sollte keine Leerzeichen enthalten und sollte auch nicht mit einer Zahl beginnen. Berücksichtigen Sie diese Konventionen zur Dateibenennung, ist Envision in der Lage, die relevanten Tabellen, die auf Lokad hochgeladen werden sollen, ohne weitere Bemühungen automatisch zu erkennen.

Vor allem stellt die Artikeltabelle einen besonderen Fall dar und es gibt für viele Envision-Skripte Vorteile, wenn die Daten um eine solche Artikel-Tabelle strukturiert werden. Doch die Artikel-Tabelle ist nicht zwingend erforderlich und Envision kann auch funktionieren, ohne eine solche Tabelle zu laden. Wird eine Datei namens Lokad_Items.xyz für Envision bereitgestellt, wird sie standartmäßig als Artikel-Tabelle behandelt.

Wird eine Tabelle in mehrere Dateien geteilt, z.B. weil die einzelnen Dateien zu groß sind, kann Envision all diese Dateien in eine Tabelle konsolidieren. Damit dies gelingt, sollten diese Dateien Lokad_TableName_Suffix.xyz benannt sein, wobei sich das Suffix unter den Dateien verändert. So kann beispielsweise, wenn tägliche Auszüge erstellt werden, eines der täglichen Auszüge Lokad_Orders_2015-03-16.tsv heißen. Das Suffix ist hier nicht bedeutend und dient lediglich der Unterscheidung der Dateien, so dass hier alles eingefügt werden kann. Natürlich erwartet Envision dieselben Spalten in allen Dateien vorzufinden, die sich nur in den Suffixen unterscheiden. Sonst kann Envision die Dateien nicht ohne weitere Anweisung zu einer Tabelle vereinen.

Aus der Sicht von Envision bestehen nicht allzu viele Erwartungen, was die Spaltennamen betrifft. Envision bietet auch verschiedene Standardverhaltensmuster:
  • Wird eine Spalte mit dem Namen If in einer Flatfile gefunden, wird die Spalte standardmäßig als Fremdschlüssel zur Id-Spalte, die ursprünglich in der Datei Lokad_Items.xyz vorgefunden wird, verwendet.
  • Wird eine Spalte so benannt, dass sie am Ende des Namens Date enthält, wird diese von Envision standardmäßig als Datum behandelt.

Sonst sind die meisten Spaltennamen zulässig, sofern sie keine Leerzeichen enthalten oder mit einer Zahl beginnen. Envision bietet aber auch Möglichkeiten, um die oben erwähnten Verhaltensmuster zu überschreiben. Dennoch empfehlen wir, soweit wie möglich, die Richtlinien zu beachten, da dies den Skript-Mehraufwand in Envision, um Ergebnisse zu liefern, senkt.

Syntax zum Lesen der Dateien

Envision unterstützt eine reiche Syntax zum Lesen von Dateien für Fälle, in denen unsere Bennenungsrichtlinien nicht befolgt werden können (z.B. wenn die Dateien nicht intern geändert werden können). Die Syntax wird unten erklärt: sie ist noch nicht ganz die allgemeine Syntax, da manche zusätzliche Optionen unten angeführt wurden).
read "/foo/bar*.xyz" as MyTable with "Foo1" as Id, "Foo2" as Date, "Foo 3" as Foo3
Der Pfad /foo/bar*.xyz kann den Platzhalter (*) enthalten, der mit jeglicher Zeichenfolge ersetzt werden kann. Es bleibt Ihnen überlassen, ob Sie einen Platzhalter nutzen möchten. Doch wenn Sie ihn nutzen, bietet er die Möglichkeit, mehrere Dateien auf einmal zu erfassen. Dieses Muster ist dem der Shell-Syntax, wenn Dateien aus einer Kommandozeile gelistet werden, ähnlich.

Das erste as Schlüsselwort, direkt hinter dem Pfad, weist den Namen der Tabelle auf. Heißt die Tabelle MyTable, bezieht sich das Envision-Skript auf diese Tabelle mit MyTable.Id. Wenn es sich bei der Tabelle, die hochgeladen werden muss, um die Artikeltabelle handelt, kann dieses as MyTable ausgelassen werden.

Die Anweisungen, die nach dem Schlüsselwort with folgen, sind Anweisungen zur Umbenennung der Spalten. Im oberen Beispiel wird die Foo1-Spalte zu Id umbenannt und die Foo2-Spalte zu Date. Dank der Umbenennung dieser beiden Spalten, sind nun die Id- und Date-Spalten korrekt definiert und die die MyTable-Tabelle wird zu einer legitimen Envision-Tabelle, in der sich historische Daten befinden.

Die dritte Umbenennung, die stattfindet, ist von Foo 3 (sehen Sie das Leerzeichen im ursprünglichen Spaltennamen) auf Foo3. Hieran können Sie erkennen, wie ein falscher Spaltenname in einen richtigen geändert werden kann. Hervorzuheben ist auch, dass die Namen der Vektorvariablen auch keine Leerzeichen zulassen. Doch der Kürze halber, haben wir keine weiteren Beispiele für umbenannte Paares angeführt. Doch solange die Paare korrekt mittels Kommas voneinander getrennt sind, können beliebig viele Umbenennungen in einer Datei stattfinden. In der Praxis kann die Umbenennung einer Spalte nützlich sein, um ein Skript verständlicher zu gestalten, doch man kann sie auch nutzen, um die erforderlichen Anpassungen vorzunehmen, wenn mehrere Dateien in einer Tabelle vereint werden müssen und die Spalten in diesen Dateien abweichende Namen besitzen.

Gehen wir davon aus, dass die historischen Daten für Bestellungen in zwei Dateien geteilt wurden. Als erstes haben wir Lokad_Orders_Old.tsv , in der alle Daten bis zum 31. Dezember 2014 beinhaltet sind. Diese Datei enthält drei Spalten namens ItemId, OrderDate und Quantity. Die Spalten dieser Datei berücksichtigen die Richtlinien Envisions für Namensgebung nicht. Anschließend haben wir Lokad_Orders.tsv, die die aktuelleren Daten ab dem 1. Januar 2015 enthält. Diese Datei besitzt auch drei Spalten namens Id, Date und Quantity, was den Richtlinien Envisions entspricht. Im unteren Skript sehen Sie, wie die Dateien in eine einzige Orders-Tabelle vereint werden können.
read "/foo/Lokad_Orders_Old.tsv" as Orders with "ItemId" as "Id", "OrderDate" as Date
read "/foo/Lokad_Orders.tsv" as Orders
Natürlich können so viele read Anweisungen wie nötig erstellt werden, um alle Dateien und Tabellen zu decken. Envision erfordert auch keine bestimmte Platzierung für diese Anweisungen, so dass sie sich technisch gesehen auch am Ende Ihres Skripts befinden können. Dennoch empfehlen wir Ihnen, diese Anweisungen am Anfang des Skripts zu platzieren, da Personen mit Programmierkenntnisse diese dort erwarten würden.

Filter mit Platzhalter

Der Platzhalter (*) bietet die Möglichkeit, mehrere Dateien auszuwählen, doch manchmal versucht man, nur eine Datei von vielen zu lesen. Wenn man nur die „letzte“ Datei beim Sortieren nach Dateinamen lesen will, kann dies, wie folgt, erreicht werden:
read max "/foo/bar*.xyz" as MyTable with "Foo1" as Id, "Foo2" as Date, "Foo 3" as Foo3

Es stehen Ihnen 3 Filter mit Platzhalter zur Verfügung:

  • min: die erste Datei, wenn Dateien nach ihren entsprechenden Namen sortiert werden (lexikografische Sortierung).
  • max: die letzte Datei, wenn Dateien nach ihren entsprechenden Namen sortiert werden (lexikografische Sortierung).
  • latest: die letzte Datei, wenn Dateien nach dem Änderungsdatum sortiert werden.

Wird beispielsweise täglich ein Snapshot des Lagerbestands als Datei namens stocks-2016-12-21.csv auf Lokad geladen, kann das Suffix angepasst werden, um das aktuelle Datum anzuzeigen. Dann werden Sie wahrscheinlich versuchen, nur die letzte Datei zu lesen. In diesem konkreten Fall würden max und latest dasselbe Ergebnis hervorbringen, da die Benennungskonvention für die Dateien mit den Aktualisierungsdaten übereinstimmt.

Typdefinition der Erwartungen

Sofern nichts anderes bestimmt wird, erwartet Envision, dass alle Tabellen, außer der Artikeltabelle eine Id- und eine Date-Spalte enthalten. Dies kann, wie im vorherigen Abschnitt gesehen, auch durch Umbenennung erreicht werden. Manchmal stimmen jedoch Tabellen nicht genau mit diesen Erwartungen überein. In diesem Falle können Sie Envision-Syntax nutzen, um die Erwartungen bezüglich einer Tabelle anzupassen. Ähnlich wird auch normalerweise die Art der Spalten vom Envision-Skript selbst abgeleitet, doch manchmal reicht diese Ableitung nicht. Hierfür bietet die Envision-Syntax erneut die Möglichkeit, die notwendige Spaltenart anzugeben.

Envision bietet die Möglichkeit, die Primärschlüssel für eine Tabelle zu definieren, indem Sie sie in Klammern nach der Definition auflisten. Es sind nur 7 Primärschlüssel-Kombinationen zulässig.
read "a.csv" as A[*]
read "b.csv" as B[Id]
read "c.csv" as C[Id, *]
read "d.csv" as D[Date]
read "e.csv" as E[Date, *]
read "f.csv" as F[Id, Date]
read "g.csv" as G[Id, Date, *]

Fall A[*] definiert eine Tabelle ohne jegliche Beschränkungen. Es ist ein Platzhalter, der für viele Szenarien genutzt werden kann. Doch wenn keine Id Spalte vorhanden ist, versäumen Sie einige der Feinheiten von der Programmiersprache Envision.

Fall B[Id] definiert eine Tabelle mit maximal einer Zeile pro Artikel. Beispielsweise fallen unsere Bestandseinstellungen unter diese Kategorie.

Fall C[Id, *] definiert eine Tabelle mit einer beliebigen Anzahl von Zeilen pro Artikel. Zum Beispiel eine Tabelle, die eine Wahrscheinlichkeitsverteilung darstellt, fällt unter diese Kategorie.

Fall D[Date] definiert eine Tabelle, die einen einzelnen Skalarwert für bestimmte Tage enthält. Eine solche Tabelle könnte zur Erstellung von nationalen Feiertagen, die auf eine bestimmte Region zutreffen, benutzt werden.

Fall E[Date, *] definiert eine Tabelle, die eine beliebige Anzahl an Skalarwerten für bestimmte Tage enthält. Dies stellt eine Erweiterung des vorangehenden Falles dar, in dem ein Tag mit mehreren Faktoren assoziiert werden kann.

Fall F[Id, Date] definiert eine Tabelle, die höchsten einen Wert für jedes [Id, Date] Paar enthält. Dies könnte beispielsweise zur Auflistung von Fehlbeständen genutzt werden.

Fall G[Id, Date, *] stellt das Standardverhalten dar, wenn die Klammern ausgelassen werden. In der Praxis fallen die meisten historischen Daten, wie etwa die der Verkaufsbestellungen, hierunter.

Einschränkungsarten in den Spalten der Tabelle

Envision ist eine Sprache mit starker Typisierung. Das bedeutet, dass alle Vektoren mit einem der in Envision vorhandenen Typen assoziiert wird: text, number, date oder boolean. Diese Typen werden gewöhnlich automatisch vom Skript abgeleitet. Doch es ist auch möglich, die Typenerwartung so festzulegen:
read "a.csv" as A[*] with "Foo" as X : text, Y : number, Z : date
Dann, gehen wir zum Beispiel-Dataset zurück, und schreiben etwa:
read "/sample/Lokad_Items.tsv"
read "/sample/Lokad_Orders.tsv" as Orders
read "/sample/Lokad_PurchaseOrders.tsv" as PO
//die drei oberen Zeilen wwerden im Folgenden ausgelassen
Quantity = sum(Orders.Quantity)
Dann wird der Vektor Orders.Quantity implizit als Zahlentyp erkannt, da nur Zahlen addiert werden können. Das bedeutet also, dass Envision die Lokad_Orders.tsv Datei parst und erwartet, dass die Quantity Spalte ein Token enthält, das erfolgreich als Zahl geparst werden kann. Wenn wir folgendes schreiben würden:
Nonsense = sum(Orders.Client)
Würde Envision versuchen, die Client Spalte der Lokad_Orders.tsv Datei mit Zahlen zu parsen und der Vorgang würde fehlschlagen, da diese Spalte das Kundenkennzeichen enthält, das keine Zahlen sind. Zusätzlich zum Mechanismus zur Typableitung, bietet Envision auch eine Syntax zur expliziten Typisierung der erwarteten Werte für jede Spalte aller Tabellen. So kann das Beispiel-Dataset mit folgender Anweisung typisiert werden:
expect Supplier : text
expect Orders.NetAmount : number
expect PO.ArrivalDate : date
Die Syntax ist die folgende: expect MyTable.MyColumn : type, wobei type eines der vier möglichen Typen darstellt: text, number, date oder boolean. Die meistverbreitete Assertion ist der Typ date, da es auf alleiniger Grundlage von Rechenoperationen und Typenableitung nicht immer möglich ist, korrekt abzuleiten, dass eine Spalte ein Datum erwartet.

Parsing-Optionen

Der Envision File-Parser ist sehr tolerant, doch in manchen Fällen bedarf er etwas Hilfe. Die skip-Option kann benutzt werden, um die N ersten Zeilen der Flatfile zu überspringen. Die Syntax lautet, wie folgt:
read "/foo/bar*.csv" skip:2 as MyTable with "Foo1" as Id, "Foo2" as Date
Im oberen Beispiel, überspringt der Parser die ersten zwei Zeilen der Flatfile und erwartet, dass sich die Spaltenüberschriften in der dritten Zeile befinden. Die skip-Option kann beliebig benutzt werden, wobei skip:0 das standardmäßige Verhalten darstellt. Diese Option ist für Systeme gedacht, die Metadaten an den Anfang der Extraktion der Flatfile setzen.

Unsafe read

Standardmäßig ist Envisions Datei-Parser strikt: Wenn ein Wert als Datum oder Zahl erwartet wird und dieser Wert nicht erfolgreich als solcher geparst werden kann, schlägt die read-Anweisung fehl. Als Faustregel, ist die beste Option, wenn Envision Parsing-Fehler findet, an erster Stelle in Erfahrung zu bringen, warum die Datei beschädigt ist. Da Envision in der Lage ist, viele Datums- und Zahlformaten zu erkennen, ist bei Fehlern die Wahrscheinlichkeit ziemlich groß, dass die Daten beschädigt sind. Datenbeschädigung kann zu vielen verschiedenen Fehlerarten führen. Wenn Envision fehlschlägt, ist dies in den meisten Fällen die sichtbare Folge eines früheren Problems.

Doch bei großen Datasets, kann es viel schwieriger sein, kleinere Datenbeschädigungen zu verhindern. Besonders, wenn die beschädigten Daten auch älter sind, kann es sich unter Umständen nicht lohnen, diese Beschädigungen zu beheben. Genau für solche besonderen Situationen, unterstützt Envision den unsafe Lesemodus, der in der unten angeführten Syntax gezeigt wird:
read "/foo/orders.tsv" unsafe with "My Id" as Id, "My Date" as Date
Wenn unsafe benutzt wird, werden Parsing-Schwierigkeiten mehr als Warnungen als als Fehler behandelt. Diese Option lässt die Ausführung von Berechnungen zu, auch wenn Werte oder Zeilen vom Parser verworfen wurden, weil sie nicht lesbar waren.