Inhaltsverzeichnis

Allgemeines

Diese Dokumentation beschreibt das Format und den Inhalt der verschiedenen Import-Dateien für Produktdaten, Kategoriedaten, Lagerbestände, kundenabhängigen Preisen, Versandkosten etc., welche an den Shop gesendet werden können.

Übertragung der Importdateien

Die Inhalte der nachfolgend beschriebenen Dateien werden mit der REST- oder SOAP-Schnittstelle in den Shop importiert:
Übertragung - Trigger: REST, SOAP & Co

Übersicht Importdateien

Derzeit werden folgende Importdateien unterstützt:

Zeichensatz der Importdateien

Es wird empfohlen, alle Importdateien im Zeichensatz des jeweiligen Subshops zu liefern.

Dadurch ist sichergestellt, dass alle importierten Sonderzeichen im Shop richtig dargestellt werden. Sobald Zeichensätze konvertiert werden müssen, besteht die Gefahr, dass es für bestimmte Zeichen keine Entsprechung im Zeichensatz des Shops gibt.

Der Zeichensatz des Subshops ist in der Datei „shop.config“, in der Sektion „Basic“ bei dem Parameter „Charset“ eingetragen.

Konvertierung der Zeichensätze

Falls das ERP-System die Zeichensätze des Subshops nicht liefern kann, so müssen diese entsprechend konvertiert werden.

Konvertierung des Zeichensatzes der "catcomplete.xml"

Bei der "catcomplete.xml" wird der Zeichensatz im Header der XML-Datei ausgewertet. Eine spezielle Konfiguration der Zeichensatzkonvertierung ist daher nicht notwendig.

Konvertierung des Zeichensatzes der Dateien "wpupdate.csv", „wpcomplete.csv“ und „*.prd“

Wenn diese Dateien konvertiert werden sollen, so muss dies in der Datei global.config im Verzeichnis „konfiguration“ des Shops eingestellt werden.

Sektion:

ConvertCharset:

Der Parameter „ConvertCharset“ legt fest, ob der Zeichensatz der Produktdaten überhaupt konvertiert wird. Die beiden anderen Parameter sind optional.

ImportCharset:

Mit „ImportCharset“ lässt sich der Zeichensatz der Importdateien festlegen, wenn er von UTF-8 abweicht.

UnknownCharacters:

Der Parameter „UnknownCharacters“ regelt, wie mit Zeichen umgegangen werden soll, für die es keine Entsprechung im Zeichensatz des SubShops gibt:

ignore: Die Zeichen werden ersatzlos weggelassen

stdreplace: Es wird versucht das Zeichen durch ein oder mehrere ähnliche Zeichen zu ersetzen

mapreplace: Die Zeichen werden anhand einer Zuordnungstabelle in der Datei global.config konvertiert

Konvertierungstabellen

Wenn in den Importdaten Zeichen verwendet werden, die im Zeichensatz des Shops nicht vorhanden sind, so können diese mit Konvertierungstabellen in der Datei global.config in andere Zeichen konvertiert werden.

Der Parameter „Charset“ gibt den Zeichensatz des Shops an, für den diese Tabelle verwendet werden soll. Alle übrigen Einträge der Sektion geben die gewünschten Ersetzungen an: Rechts vom „=“ steht die Zeichenfolge in der Importdatei, links davon die Zeichenfolge durch die sie ersetzt werden soll. Sowohl die Original-Zeichen als auch die Ersetzung müssen im Zeichensatz der Importdatei kodiert werden.

Alle Zeichen können URL-kodiert werden. Dabei folgt auf ein „%“ Zeichen der hexadezimale Code des Zeichens. Diese Kodierung ist bei allen Sonderzeichen (mit einem Code >= 128) empfehlenswert, da ansonsten die Gefahr besteht, dass diese Zeichen beim Bearbeiten der Datei im falschen Zeichensatz gespeichert werden.

Bemerkungen
Wenn eine Zeichenfolge nicht durch eine andere ersetzt, sondern gelöscht werden soll, so lässt sich das mit dem Spezialwert „$delete“ erreichen.

• Die Konvertierungstabellen werden derzeit nur für die Konvertierung der Produktdaten verwendet, nicht für die Kategoriedaten.

• Es können beliebig viele <+ImportCharsetConvertMap> Sektionen in der Datei global.config stehen. Allerdings müssen sie sich im „Charset“ Parameter unterscheiden.

Formate der Importdateien

Allgemeines

Alle Dateien mit den Extensions „csv“ und „prd“ werden in einem „character separated values“ Format gespeichert, d.h. die Dateien bestehen aus einer Header-Zeile mit den Feldnamen und beliebig vielen Datenzeilen, sowie Feldtrennern zwischen den Feldern einer Datenzeile. Feldtrenner für die Feldwerte bzw. die Feldnamen in der Header-Zeile sind Tabulator-Zeichen. Die Zeilen werden mit einem CR oder einem CRLF abgeschlossen.
Bitte achten Sie bei den Feldnamen auf die Groß-/Kleinschreibung.

Beispiel:
HeaderFeld1<TAB>HeaderFeld2<TAB>HeaderFeld3<CRLF>
Feldwert1a<TAB>Feldwert2a<TAB>Feldwert3a<CRLF>
Feldwert1b<TAB>Feldwert2b<TAB>Feldwert3b<CRLF>

Datentypen

In den nachfolgenden Tabellen werden folgende Datentypen verwendet:

Maximale Länge der Felder

Die in den Tabellen angegebene maximalen Längen werden beim Import nicht geprüft. Felder, bei denen die maximale Länge überschritten ist, werden nicht gekürzt, weder beim Import noch später bei der Anzeige im Shop.

Der Grund dafür ist, dass Felder (speziell die Produktbeschreibung) HTML-Formatierungen enthalten können. Würde nun z. B. eine Produktbeschreibung nach einem öffnenden <table> Tag abgeschnitten, aber noch vor dem schließenden </table> Tag, so wäre nicht nur die Formatierung des Feldwertes selbst betroffen, sondern die Formatierung des gesamten Inhalts der HTML-Seite, der auf die Beschreibung folgt. Im schlimmsten Fall wäre nicht nur die Darstellung der Seite betroffen, sondern auch die Funktion, wenn z. B. der „In den Warenkorb“ Button nicht mehr angezeigt wird.

Aus diesem Grund werden Felder, bei denen die maximale Länge überschritten ist, im Shop nicht bzw. mit leerem Inhalt angezeigt.

Produktdaten (wpupdate.csv/wpcomplete.csv)

Diese Dateien enthalten die zu ändernden oder neu in den Shop einzufügenden Produktdaten.

Liste der Felder (unstrukturiert)

Die Datei kann folgende Felder enthalten:

Nicht verwendete Felder können weggelassen werden, aber Sie sollten bei jedem Import die gleichen Felder in der gleichen Reihenfolge verwenden. Wenn Sie Felder hinzufügen, Felder löschen oder die Reihenfolge der Felder ändern, dann müssen die bereits im Shop gespeicherten Daten beim Import an die neuen Felder angepasst werden, was den Importvorgang erheblich verlängern kann.

Zusätzlich zu den oben aufgelisteten Feldern kann die Importdatei die im WSPManager für den Subshop angelegten freien Felder enthalten (Zulässige Zeichen/max. Länge: S1/16000). Die Spaltenüberschriften in der Importdatei müssen dabei den im WSPManager eingetragenen "Technischen Feldnamen" entsprechen.

Meta-Felder (strukturiert)

WEBSALE Meta-Felder werden auch als Mehr-Wert-Felder oder Mehr-Bereichsfelder bezeichnet, weil in ihnen mehrere Attribute (Werte) in einem Feld übergeben werden können.

Um die Tabellenstruktur schlank und übersichtlich zu halten, besitzen manche Felder eine zusätzliche innere Struktur, Dadurch können in einem Tabellenfeld eine von Produkt zu Produkt unterschiedliche Anzahl von Parametern und Werten angegeben werden, z. B. Staffelpreise.

BulkDiscount/Staffelpreise

Die Staffelpreise werden in folgendem Format in einem Tabellenfeld übergeben:

<g><1>Mengen-Typ 1</1><2>Menge 1</2><3>Preis 1</3><4>Preis-Typ 1</4><5>Grundpreis 1</5></g>
<g><1>Mengen-Typ 2</1><2>Menge 2</2><3>Preis 2</3><4>Preis-Typ 2</4><5>Grundpreis 2</5></g>

(Der Zeilenumbruch ist nicht Teil des Formats und dient nur der besseren Lesbarkeit.)

Jeder Datensatz wird von den Tags „<g>“ und „</g>“ umrahmt. Innerhalb des Datensatzes gibt es weitere Tags für Preis-Typ, Menge und Preise.

Beispiel:
<g><1>0</1><2>2</2><3>3.5</3><4>0</4><5>5,00 EUR / kg</5></g>
<g><1>0</1><2>4</2><3>1.9</3><4>0</4><5>2,71 EUR / kg</5></g>

(Der Zeilenumbruch ist nicht Teil des Formats und dient nur der besseren Lesbarkeit.)

BulkDiscountPrices/Aktionspreise

Aktionspreise können Sie verwenden, wenn Preise sowohl mengenabhängig als auch zeitabhängig sein sollen. Für jede Zeit-/Mengenstaffel wird dafür sowohl im Feld BulkDiscount als auch im Feld BulkDiscountPrices ein Eintrag benötigt.

BulkDiscount

Für jede Zeit-/Mengenstaffel muss zusätzlich zu den dort eventuell vorhandenen, zeitunabhängigen Staffelpreisen ein zusätzlicher Eintrag in das BulkDiscount-Feld eingefügt werden, der den folgenden Aufbau hat:

<g><1>Mengen-Typ 1</1><2>Menge 1</2><4>Preis-Typ 1</4></g>
<g><1>Mengen-Typ 2</1><2>Menge 2</2><4>Preis-Typ 2</4></g>

(Der Zeilenumbruch ist nicht Teil des Formats und dient nur der besseren Lesbarkeit.)

Der Aufbau entspricht weitgehend dem der „normalen“ Staffelpreise, mit dem Unterschied, dass der Tag „<3>“ komplett entfällt, und der Tag „<4>“ andere Werte enthält.

Beispiel:
<g><1>0</1><2>5</2><4>2</4>

BulkDiscountPrices

Für jeden zusätzlichen, zeitabhängigen Preis im „BulkDiscount“ Feld muss mindestens ein Eintrag in das Feld „BulkDiscountPrices“ eingefügt werden, der die eigentliche Zeitabhängigkeit und den Preis enthält.

Das Feld hat den folgenden Aufbau:

<aMenge><1>Start-Zeitpunkt</1><2>End-Zeitpunkt</2><3>Preis</3><4>Typ</4></aMenge>
<gMenge><1>Start-Zeitpunkt</1><2>End-Zeitpunkt</2><3>Preis</3><4>Typ</4></gMenge>

(Der Zeilenumbruch ist nicht Teil des Formats und dient nur der besseren Lesbarkeit.)

„Menge“ wird dabei durch die Menge ersetzt, die im Tag „<2>“ des zugehörigen Eintrags im „BulkDiscount“ Feld eingetragen ist.

Für jeden Eintrag im Feld BulkDiscountPrices muss es einen Eintrag im Feld BulkDiscount geben, der in der Menge und beim Wert des Tags <4> mit dem Eintrag in BulkDiscountPrices übereinstimmt.

<a5><1>1432652273</1><2>1432652283</2><3>10.00</3><4>2</4></a5>

Bemerkung:

Wenn mehrere Preise mit überlappenden Zeiträumen importiert werden, so wird im Shop der niedrigste Preis verwendet.

AltPrices

In diesem Feld können zusätzliche, zeitabhängige Preise importiert werden. Gibt es für den aktuellen Zeitpunkt keinen gültigen Preis, so wird stattdessen der unter „Price“ importierte Preis verwendet.

Sind mehrere Zeiträume gültig, so wird der niedrigste Preis verwendet.

Soll der Start- oder Endzeitpunkt nicht verwendet werden, so muss dort „0“ als Zeitpunkt eingetragen werden.

Die alternativen Preise werden in folgendem Format in einem Tabellenfeld übergeben:

<g><1>Start-Zeitpunkt</1><2>End-Zeitpunkt</2><3>Preis</3></g>
<g><1>Start-Zeitpunkt</1><2>End-Zeitpunkt</2><3>Preis</3></g>

(Der Zeilenumbruch ist nicht Teil des Formats und dient nur der besseren Lesbarkeit.)

Jeder Datensatz wird von den Tags „<g>“ und „</g>“ umrahmt, Innerhalb des Datensatzes gibt es weitere Tags für Start-Zeitpunkt, End-Zeitpunkt und Preis.

Analog zu den „alternativen Preisen“ können mit dem Tag „a“ auch „Aktionspreise“ definiert werden. Diese werden im angegebenen Zeitraum bevorzugt (d.h. vor den alternativen Preisen) verwendet.

Beispiel:
<g><1>1210892400</1><2>1240892500</2><3>3.5</3></g><g><1>1240892401</1><2>1250892401</2><3>1.9</3></g><a><1>1210892450</1><2>1240892400</2><3>1.2</3></a>

OrgPrices

Das Format entspricht dem des Feldes AltPrices, allerdings gibt es im Feld OrgPrices keine Aktionspreise.

Beispiel:
<g><1>1210892400</1><2>1240892500</2><3>3.5</3></g><g><1>1240892401</1><2>1250892401</2><3>1.9</3></g>

AreaProductPriceScale/Staffelpreise für Flächenprodukte

Mit diesem Feld können Staffelpreise für Flächenprodukte definiert werden. Staffelpreise für Flächenprodukte können nicht mit kundenabhängigen/preisgruppenabhängigen Preisen oder zeitabhängigen Preisen kombiniert werden.

Der Inhalt des Feldes muss in folgendem Format geliefert werden:

(<ab-Größe>:<Preis>)(<ab-Größe>:<Preis>)...

Beispiel:
(0:12.99)(100:11.99)(199:10.99)(1000:8.99)

TextInputFields/Texteingabefelder

Hierzu kann der Besteller ein oder mehrere Eingaben zum Produkt (z. B. Texte zur Beflockung) hinterlegen.

Die Texteingabefelder werden in folgendem Format gespeichert:

(Die Zeilenumbrüche und Einrückungen sind nicht Teil des Formats und dienen nur der besseren Lesbarkeit.)

Die Daten eines einzelnen Texteingabefeldes werden von den Tags „<g>“ und „</g>“ umrahmt. Innerhalb des Datensatzes gibt es weitere Tags für Beschriftung, Anzahl der sichtbare Zeichen, Anzahl Zeilen, die Maximal Anzahl von Zeichen und „Eingabe erforderlich“.

Beispiel:
<g><1>Aufdruck vorne</1><2>30</2><3>1</3><4>50</4><5>y</5></g><g><1>Aufdruck hinten</1><2>30</2><3>2</3></g>

Variations „normale Varianten“

Bei den normalen Varianten können nur einige Produktattribute von der Variante (Größe, Farbe, Höhe, Breite, etc.) abhängig sein.

Für die normalen Varianten gilt folgendes Format:

(Die Zeilenumbrüche und Einrückungen sind nicht Teil des Formats und dienen nur der besseren Lesbarkeit.)

Beispiel:
<g><vn>Farbe</vn><ve><1>Rot</1></ve><ve><1>Gelb</1><2>5.00</2><5>y</5></ve><ve><1>Grün</1><3>08-GR</3></ve></g>

DepVariations/DepVarFile, „abhängige Varianten“

Bei den abhängigen Varianten, können die meisten Produktattribute wie:

• Preis

• Produktnummer

• Lagerbestand

• Bebilderung

• Bezeichnung/Beschreibung

• etc.

von der Variante (Größe, Farbe, Höhe, Breite, etc.) abhängig sein.

Der Hauptteil der Daten von abhängigen Varianten wird je Produkt in einer eigenen „PRD-Datei“ gespeichert. Die wpupdate.csv/ wpcomplete.csv Dateien enthalten nur die Namen der verwendeten Varianten und einen Verweis auf die PRD-Datei.

Namen der Varianten

Die Namen der Varianten werden im Feld „DepVariations“ gespeichert, es hat folgenden Aufbau:

<g><vn>Variationsname 1</vn></g><g><vn>Variationsname 2</vn></g><g>...

Beispiel:
<g><vn>Farbe</vn></g><g><vn>Größe</vn></g>

Bestellmengen als abhängige Varianten

In bestimmten Fällen kann es sinnvoll sein, die möglichen Bestellmengen über eine abhängige Variation zu realisieren. In diesem Fall wird der in der PRD-Datei angegebene Preis nicht mit der Menge multipliziert sondern unverändert im Shop angezeigt.

Ein Nachteil ist, dass sich die Größe der PRD-Dateien vervielfacht. Je nach dem wie viele andere Varianten und Variationseinträge das Produkt noch hat können schnell mehrere tausend Zeilen zusammenkommen, was zu einer spürbaren Verlangsamung der Onlineshops führen kann. Beachten Sie auch, dass je Produkt nicht mehr als 100000 abhängige Varianten importiert werden können.

Um einer Variation als Menge zu kennzeichnen muss ihr der Präfix „$1$“ vorangestellt werden.

Beispiel:
<g><vn>Farbe</vn></g><g><vn>Größe</vn></g><g><vn>$1$Menge</vn></g>

Name der PRD-Datei

Der Verweis auf die PRD-Datei wird im Feld „DepVarFile“ abgelegt. Der Inhalt besteht aus dem Unterverzeichnis in dem die Datei liegt und dem Namen der Datei selbst.

Beispiel:
deutsch_491.prd/PFLS744.prd

Die Namen der Verzeichnisse und der PRD-Dateien selbst werden nach einem fest vorgegebenen Schema gebildet.

Der Dateiname wird aus dem Produktindex + der Extension „.prd“ gebildet. Lautet also der Produktindex beispielsweise „ABCxyz“, so ist der Name der zugehörigen PRD-Datei „ABCxyz.prd“. Enthält der Produktindex Zeichen, die in Dateinamen nicht zulässig sind (\,/,:,*,?,“,<,>,|) so müssen diese „escaped“ werden. Das gleiche gilt für alle Zeichen mit ASCII-Code>127 (insbesondere Umlaute) und das Zeichen „%“.

Als Escape-Mechanismus wird der gleiche wie bei URLs verwendet, d. h. das unzulässige Zeichen wird durch „%“ + den zweistelligen Hexcode (in Kleinbuchstaben) des Zeichen-Codes ersetzt.

Aus dem Produktindex „123/abc“ würde sich also der PRD-Dateiname „123%2fabc.prd“ ergeben.

Es wird empfohlen den Produktindex so zu wählen, dass kein Escaping nötig ist.

Bitte beachten Sie, dass das vom Shop verwendete Dateisystem zwischen Groß- und Kleinschreibung unterscheidet. Wenn also der Produktindex „abc“ lautet, dann muss die PRD-Datei den Namen „abc.prd“ haben. Der Name „ABC.PRD“ wäre z. B. ungültig und würde zu Fehlern beim Anzeigen der abhängigen Varianten führen.

Der Name des Verzeichnisses ergibt sich aus dem Subshop des Produkts und einem aus dem Produktindex gebildeten Hash-Wert.

Verzeichnisname = <Subshop> + „_“ + Prodindex-Hash + „.prd“

Aus dem Produkt-Index wird zunächst der MD5-Hash-Wert gebildet. Die ersten zwei Bytes dieses Hash-Wertes werden als integer interpretiert (Byte1 + 256*Byte2) und modulo 1000 genommen.

Beispiel:

Der Inhalt der PRD-Dateien wird in einem eigenen Kapitel („PRD-Dateien“) beschrieben.

CrossLinks

Dieses Feld kann die Daten sowohl für "CrossLinks" als auch für die artverwandten Daten von "CrossSellingLinks" und von "Ersatzartikeln" enthalten.

Das Feld hat folgendes Format:

<g><1>Produktindex</1><2>Kategorieindex</2><3>Link-Typ</3><4>Produktnummer (nur bei Verlinkung auf Variante)</4></g><g>...

Beispiel:
<g><1>23110001</1><3>2</3></g><g><1>23474</1><2>3121-34</2><3>2</3></g>

Inventory (Lagerbestandsverwaltung aktivieren)

Dieses Feld enthält den statischen Teil der Lagerbestandsdaten (Aktivierung der Lagerbestandsverwaltung, Limits, Status-Texte etc.).

Die Übergabe des eigentlichen Lagerbestandes erfolgt über eine separate Lagerbestandsdatei: siehe Lagerbestände (amountupdate.csv)

Das Feld hat folgenden Aufbau:

(Die Zeilenumbrüche sind nicht Teil des Formats und dienen nur der besseren Lesbarkeit.)

Beispiel:
<1>y</1><11>0</11><12>10</12><21>sofort lieferbar</21><22>sofort lieferbar</22><23>leider vergriffen</23>

Download-Artikel

Dieses Feld enthält die für Download-Artikel nötigen Daten, es hat folgenden Aufbau:

(Der Zeilenumbruch ist nicht Teil des Formats und dient nur der besseren Lesbarkeit.)

Beispiel:
<1>y</1><2>download.zip</2><3>48</3><4>10</4>

Set

Dieses Feld enthält die Set-Unterartikel eines Sets, es hat folgenden Aufbau:

(Die Zeilenumbrüche sind nicht Teil des Formats und dienen nur der besseren Lesbarkeit.)

Beispiel:
<g><1>DA634108</1><3>1</3><5>y</5></g><g><1>DA613740</1><2>y</2><3>2</3></g><g><1>AA650659</1><3>1</3></g>

SetConfiguration

Dieses Feld enthält eine Metadatenstruktur, die zusätzliche Optionen zu den Setartikeln enthält.

Derzeit kann dieses Feld nur ein Tag enthalten:

Beispiel:
<IgnoreChildInventory>y</IgnoreChildInventory>

ChildProducts

Dieses Feld enthält die Daten der Gruppierungs-Unterartikel. Es hat den gleichen Aufbau wie das CrossLinks-Feld, als Typ wird „0“ eingetragen.

ProductComparisonFields/Vergleichsfelder

Mit ProductComparisonFields lassen sich die Felder importieren, die beim Produktvergleich im Shop verwendet werden können. Die Vergleichseigenschaft wird aus dem (freien) Feld mit dem technischen Namen gelesen.

Es hat folgenden Aufbau (alte Logik):

(Die Zeilenumbrüche und Einrückungen sind nicht Teil des Formats und dienen nur der besseren Lesbarkeit.)

Beispiel:
<g><1>MerchantName</1></g><g><1>Width</1></g>

Parallel zu der “alten“Logik kann das ProductComparisonFields erweitert werden, wodurch unterschiedliche Vergleichsattribute in den selben freien Feldern gepflegt werden können:

(Die Zeilenumbrüche und Einrückungen sind nicht Teil des Formats und dienen nur der besseren Lesbarkeit.)

Beispiel:

<g><1></1><2>alternative-MerchantName</2><3>Hersteller</3></g>

Ist kein technischer Feldname in <1> angegeben wird die Beschreibung des Vergleichsfeldes (in <3>) verwendet.

Die Vergleichseigenschaft wird aus dem freien Feld mit dem technischen Namen wie unter<2> angegeben gelesen.

Alte und neue Logik können auch gemischt werden, sowohl zwischen unterschiedlichen Produkten als auch innerhalb des Felds "ProductComparisonFields".

AreaProductRange/Optionen für Flächenprodukte

Bei Flächenprodukten kann der Kunde bei der Bestellung im Shop die Abmessungen des Produkts eingeben, also z. B. Höhe 2m, Breite 1,5m. Der Shop berechnet aus den Abmessungen die Fläche und multipliziert sie mit dem "Einzelpreis" des Produkts, um den finalen Preis zu ermitteln.

Ob ein Produkt ein "Flächenprodukt" ist, wird in dem Feld "AreaProduct" angegeben (siehe "Standardfelder").

In dem erweiterten Feld "AreaProductRange" werden zusätzliche Beschränkungen der Abmessungen importiert, so dass der Kunde im Shop z. B. nur Breiten eingeben kann die zwischen 0,5 und 2,5m liegen.

Da Flächenprodukte normalerweise nicht in beliebigen Abmessungen lieferbar sind müssen alle vier Felder gefüllt werden, ansonsten lässt sich das Produkt im Shop nicht bestellen.

Das Feld hat folgenden Aufbau:

(Die Zeilenumbrüche sind nicht Teil des Formats und dienen nur der besseren Lesbarkeit.)

Beispiel:
<minlen>1.5</minlen><maxlen>2.5</maxlen><minwidth>0</minwidth><maxwidth>3</maxwidth>

VariationsOverview/VariationsOverviewMatrix/Bekleidungsmodul

Die Daten in diesen beiden Feldern ermöglichen es dem Shop auch bei nur teilweise aufgelösten abhängigen Varianten ein passendes Bild anzuzeigen. Dies ist bei der Suche nach Produkten der Fall (z. B. Suche nach "Hose rot"), bei Kategoriefiltern (z. B. Filterung nach roten Produkten) und bei der Suche nach Teilartikelnummern.

Weiterhin ermöglichen es diese Daten bei der Variantenauswahl Bilder des Produkts anzuzeigen, also z. B. statt einer Auswahlliste mit "rot" und "grün" zwei Bilder auf denen das Produkt jeweils in "rot" und "grün" abgebildet ist.

Die Anzahl der Varianten für dieses Feature ist auf maximal 2 beschränkt.

VariationsOverview

Dieses Feld enthält Namen und Werte der Varianten, sowie für jeden Wert die anzuzeigenden Bilder und einen (optionalen) anzuzeigenden Text.

Beispiel:

(Die Zeilenumbrüche und Einrückungen sind nicht Teil des Formats und dienen nur der besseren Lesbarkeit.)

VariationsOverviewMatrix

Dieses Feld enthält in kompakter Form ("Matrix") die zulässigen Kombinationen der Variationswerte und die zugehörigen Produktnummern. Dabei entsprechen die Werte der ersten Variante den Spalten und die Werte der zweiten Variante den Zeilen. In den Zellen der Matrix steht entweder die Nummer des zu der Kombination gehörenden Produkts oder ein leerer Wert, wenn es zu der Kombination kein passendes Produkt gibt.

Beispiel: Die erste Variante ist "Größe" und hat die Werte "S", "M" und "L", die zweite Variante ist "Farbe" und die Werte "rot" und "grün".

Dann könnte die Matrix so aussehen:

In dem eigentlichen Feldwert von "VariationsOverviewMatrix" werden die Variationswerte weggelassen, die Spalten durch "|" Zeichen voneinander getrennt und die Zeilen durch ein ">" Zeichen.

Für das Beispiel oben ergibt sich also folgender Feldwert:

1234-s-r|1234-m-r|1234-l-r>1234-s-g|1234-l-g

Eine Escape-Mechanismus für die Zeichen "|" und ">" ist nicht vorgesehen, d. h. bei Verwendung des "Bekleidungsmoduls" dürfen diese Zeichen in Produktnummern nicht vorkommen.

Bekleidungsmodul und PRD-Dateien

Bei Verwendung des Bekleidungsmoduls mit zwei Varianten müssen die Zeilen in der PRD-Datei nach den Werten der ersten Variante sortiert sein. Die Reihenfolge (z. B. aufsteigend oder absteigend) ist dabei nicht relevant, wichtig ist nur, dass Zeilen mit gleichen Variationswerten zusammenstehen.

Beispiel "richtig":

Beispiel "falsch":

InstantVoucherProduct/Gutscheinprodukte

In diesem Feld werden die Daten für Gutscheinprodukte übergeben, d. h. von Produkten, mit denen ein Kunde im Shop Gutscheine kaufen kann.

Beispiel:
<g><1>y</1><2>Kaufgutscheine</2><3>y</3><4>y</4></g>

Typen der freien Felder

Neben dem Namen kann beim Anlegen eines freien Feldes im WSPManager auch ein "Typ" angegeben werden.

Bei den Typen "Text Aufzählung" und "Meta-Feld" muss das Format der Felder beachtet werden, alle anderen Typen können beliebigen Text enthalten.

Text Aufzählung

Die einzelnen Punkte der Aufzählung müssen mit <g></g> umrahmt werden.

Beispiel:
<g>Punkt 1</g><g>Punkt 2</g>

Meta-Feld

Mit einem Meta-Feld können Sie mehrere Produktattribute in ein einzelnes Feld schreiben, diese Attribute können dann im Shop einzeln angezeigt werden.

Die einzelnen Werte werden jeweils von Tags umrahmt, die aus der fortlaufenden Nummer des Produkt-Attributs gebildet werden.

Beispiel:
<1>Feature-Beschreibung</1><2>BildZumFeature.jpg</2><3>PDFZumFeature.pdf</3>

Produktdaten und Variationswerte für abhängige Varianten (PRD-Dateien)

Zu jedem Produkt mit abhängigen Varianten muss eine eigene PRD-Datei erzeugt werden. Inhalt der Datei sind die Werte der abhängigen Varianten und die abweichenden Produktdaten. Der Name und das Verzeichnis der Datei entspricht dem im Feld „DepVarFile“ eingetragenen Werte in der wpupdate.csv/wpcomplete.csv Datei.

Variationswerte

Die Variationswerte werden in Spalten übergeben deren Überschrift mit dem Präfix „$Var_“ beginnt. Die verschiedenen Werte für die Variation „Größe“ würden also z. B. in der Spalte „$Var_ Größe“ stehen.

Für jede im Feld „DepVariations“ der wpupdate.csv/wpcomplete.csv angegebene Variation muss es in der PRD-Datei des Produktes eine zugehörige Spalte geben.

Wichtig: Die Reihenfolge der „$Var_“ Spalten muss die gleiche sein wie im „DepVariations“ Feld der wpupdate.csv/wpcomplete.csv. Enthält „DepVariations“ also z. B. den Wert „<g><vn>vn1</vn></g><g><vn>vn2</vn></g>“ so muss in der PRD-Datei die Spalte „$Var_vn1“ vor bzw. links von der Spalte „$Var_vn2“ stehen.

Beachten Sie, dass die Reihenfolge, in der die Variationswerte in der PRD-Datei stehen auch bestimmt, in welcher Reihenfolge die Werte im Online-Shop zur Auswahl angeboten werden.

„Unbenutzte“ Variationswerte

Gelegentlich kann es vorkommen, dass manche der Varianten im Shop übersprungen werden sollen.

Beispiel: Sie bieten in Ihrem Shop Handys an, wahlweise mit oder ohne Vertrag. Eine der abhängigen Varianten hätte dementsprechend die Werte „Mit Vertrag“ und „Ohne Vertrag“. Weitere Varianten wären „Netz“ (z. B. „T-Mobile“) und „Farbe“. Sobald nun der Kunde den Variationseintrag „Ohne Vertrag“ auswählt macht es keinen Sinn mehr ihn nach dem gewünschten Netz zu fragen. Diese Variation sollte im Shop in diesem Fall gar nicht erst angezeigt werden, der Kunde sollte nur noch die gewünschte Farbe auswählen müssen.

Für solche Fälle kann der Spezialwert „$_$“ für einen Variationswert importiert werden um diesen als unbenutzt zu kennzeichnen.

Der relevante Teil der PRD-Datei könnte für diesen Fall beispielsweise so aussehen:

Beachten Sie, dass Sie den Wert „$_$“ nicht mit anderen, normalen Variationseinträgen mischen können. Folgende Zeilen in der obigen Beispieldatei wären also fehlerhaft:

Die Werte für die erste Variation sind in diesen beiden Zeilen gleich. Da für die zweite Variation der Wert „$_$“ verwendet wird muss dieser Wert für alle Zeilen verwendet werden die als Wert für die erste Variation „Ohne Vertrag“ haben.

Soll „$_$“ als Wert für die dritte oder eine folgende Variation verwendet werden, so gilt diese Logik analog.

Abweichende Produktdaten

Neben den Variationswerten können in der PRD-Datei auch (von den Daten in der wpupdate.csv/wpcomplete.csv) abweichende Produktdaten stehen. Die Spaltenüberschriften und Datenformate in der PRD-Datei entsprechen denen in der wpupdate.csv/wpcomplete.csv.

Wenn eine Spalte mit einem Produktdatenfeld vorhanden ist, so überschreiben die dort angegebenen Werte die in der wpupdate.csv/wpcomplete.csv angegebenen, sobald der Kunde im Shop den entsprechenden Variationseintrag ausgewählt hat. Dies gilt auch dann, wenn der Wert leer ist!

Wenn Sie für einzelne Einträge in der PRD-Datei nicht wollen, dass der Wert aus der wpupdate.csv/wpcomplete.csv überschrieben wird, so können Sie dies erreichen, indem Sie einen Bindestrich („-“) als Wert eintragen.

Einige wenige Produktdatenfelder sind von der Verwendung in den PRD-Dateien ausgenommen:

• BestPrice

• ChildProducts

• DepVarFile/DepVariations

• Event

• EventDiscount

• EventProductNumber

• InsertList

• License

• SearchItems

• Test

• Variations

• ValidUntil

• ValidFrom

Schließlich gibt es in der PRD-Datei noch ein Feld „VarIndex“ dessen Bedeutung analog zum Feld „Prodindex“ in der Datei wpupdate.csv/wpcomplete.csv ist. Der Inhalt dieses Feldes muss Subshop-weit eindeutig sein.

Beispiel:

In diesem Beispiel werden die Produktnummern und die Produktbilder an den ausgewählten Variationseintrag angepasst. Für den Eintrag L/gelb ist als Wert „-“ eingetragen, das bedeutet wenn dieser Eintrag gewählt wird, dann wird im Shop das in der wpupdate.csv/wpcomplete.csv Datei eingetragene Bild angezeigt.

Für ein Produkt können maximal 100000 abhängige Varianten importiert werden. Es wird jedoch empfohlen deutlich unter diesem Limit zu bleiben, da der Onlineshop bereits bei mehr als 10000 abhängigen Varianten spürbar langsamer wird, d.h. der Kunde im Shop nach jeder Auswahl mehr oder weniger lange warten muss, bis die angezeigte Seite aktualisiert wird.

Löschen von Produktdaten (wpdelete.csv)

Diese Datei enthält Produkte, die aus dem Subshop gelöscht werden sollen. Die Datei enthält eine einzige Spalte mit dem Namen „ProdIndex“.

Beispiel:
ProdIndex
123-abc
789-xyz

Produkt-Kategorie-Zuordnungen

Anlegen und Ändern (catupdate.csv/catcomplete.csv)

Diese Dateien enthalten die Zuordnungen der Produkte zu den Kategorien im Subshop. Beim Import der Datei catupdate.csv wird nur der Inhalt der in der Datei aufgeführten Kategorien aktualisiert. Der Inhalt aller anderen Kategorien bleibt unverändert. Beim Import der Datei catcomplete.csv dagegen wird der Inhalt der Kategorien gelöscht, für die in der Datei keine Daten geliefert werden, d.h. diese Datei muss alle Produkt-Kategorie-Zuordnung für den Subshop enthalten.

Das Format der beiden Dateien ist identisch, sie enthalten folgende Felder:

Beispiel:

Bemerkungen:

• Wenn für eine Kategorie Daten geliefert werden, dann müssen alle Zuordnungen geliefert werden. Zuordnungen, die nicht in der Datei vorhanden sind, werden aus der Kategorie gelöscht.

• Eine explizite Angabe der Reihenfolge ist optional. Wenn das Feld „Order“ fehlt, werden die Produkte in der Reihenfolge in den Shop eingelesen in der sie in der Datei stehen.

• Für die in einer catcomplete.csv vorhandenen Produkte müssen die zugehörigen Produktdaten in der wpcomplete.csv (und eventuell nötigen PRD-Dateien) geliefert werden.

• Für die in einer catupdate.csv vorhandenen Produkte müssen die zugehörigen Produktdaten in der wpupdate.csv und (eventuell nötigen PRD-Dateien) geliefert werden, sofern die Produkte nicht bereits im Shop vorhanden sind.
  Wenn möglich empfiehlt es sich die Daten der in der catupdate.csv vorhandenen Produkte trotzdem immer mit der zugehörigen wpupdate.csv Datei zu importieren. Ein Vorteil dieser Vorgehensweise ist, dass der Import schneller geht, da ein Zugriff auf einzelne Produkte im Shop langsamer ist als auf die Produktdaten in den Importdateien.
  Weiterhin ist es für das System das die Importdateien erstellt eine schwierige Aufgabe darüber Buch zu führen, welche Produkte denn schon im Shop vorhanden sind, so dass leicht Fehler entstehen können, die zu fehlenden Produkten im Shop führen.

Löschen von Produkt-Kategorie-Zuordnungen (catdelete.csv)

Diese Datei ermöglicht es alle Produktzuordnungen aus einer Kategorie zu löschen ohne deshalb sämtliche Zuordnungen mit der Datei catcomplete.csv neu einlesen zu müssen. Mit der catupdate.csv ist dies nicht möglich, da der Inhalt von Kategorien, die nicht in dieser Datei auftauchen, unverändert bleibt.

Die Datei enthält eine einzelne Spalte mit dem Namen „CatIndex“, die den Kategorieindex derjenigen Kategorien enthält, aus denen alle Produkte entfernt werden sollen.

Beispiel:
CatIndex
cat-1
cat-2

Kategoriedaten (catcomplete.xml)

Sie können die Kategoriedaten entweder im WSPManager pflegen oder über die Datei „catcomplete.xml“ importieren. Welche der beiden Möglichkeiten aktiv ist wird bei der Freischaltung festgelegt. Falls Sie von manueller Pflege auf Import (oder umgekehrt) umstellen möchten, dann müssen Sie sich an die WEBSALE AG wenden.

Im Falle der Pflege der Kategoriedaten mit dem WSPManager muss diese auf dem gleichen PC erfolgen auf dem auch der Import erfolgt.

Bei der Import-Lösung muss die Datei "catcomplete.xml" die vollständige Kategoriestruktur des Shops enthalten. Kategorien die nicht in dieser Datei stehen werden beim Import gelöscht.

Als einzige Importdatei hat die „catcomplete.xml“ ein XML-Format, da dieses Format für hirarchische Strukturen mit vielen optionalen Feldern kompakter ist.

Das Wurzelelement der Datei heißt „categories“, darunter liegt das Element „menucategories“ und das optionale Element „nomenucategories“. Unterhalb von „menucategories“ liegen die „category“ Elemente mit den eigentlichen Kategoriedaten.

Unterhalb von „nomenucategories“ können die Daten der „Happy Hour“ Kategorien übergeben werden. Andere Kategorien sollten dort nicht stehen.

Die Daten der Kategorien werden als Attribute oder als Unterelemente des „category“ Tags übergeben. Unterkategorien werden ebenfalls als Unterelemente importiert.

Das „category“ Tag hat folgende Attribute:

Folgende (optionale) Unterelemente kann das „category“ Tag enthalten:

Beispiel:

Versteckte Kategorien

Der Import von versteckten Kategorien erfolgt genauso wie der Import von Kategorien die im Shopmenü angezeigt werden sollen, mit dem einen Unterschied, dass für diese Kategorien im Unterelement „hide“ der Wert „y“ übergeben werden muss.

Beispiel:

In diesem Beispiel wird die Kategorie „Show in Menu“ im Shopmenü angezeigt, die Kategorie „Do not show in Menu“ nicht.

Lagerbestände (amountupdate.csv)

Diese Datei enthält die Lagerbestände für die Produkte. Im Gegensatz zu den meisten anderen Importdateien wird diese Datei nur einmal je Shop importiert, gilt also für alle Subshops.

Hintergrund ist die Überlegung, dass in verschiedenen Subshops angebotene Produkte normalerweise im gleichen Lager liegen. Würde der Lagerbestand je Subshop verwaltet werden, so würde im Shop mit einem fehlerhaften Bestand gerechnet werden. Beispiel: Ein Shop hat die beiden Subshops „deutsch“ und „englisch“, das Produkt „abc“ hat einen Lagerbestand von „5“. Würde der Bestand in den beiden Subshops getrennt verwaltet werden, so könnten im Online-Shop 10 Stück des Produkts „abc“ verkauft werden, obwohl nur 5 Stück vorhanden sind.

Soll die Lagerbestandsverwaltung für unterschiedliche Subshops getrennt werden, so kann man dies erreichen, in dem man den Produkten je Subshop unterschiedliche Lagerartikelnummern gibt, z. B. „abc-deutsch“ für den deutschen Subshop und „abc-englisch“ für den englischen Subshop.

Die Datei enthält folgende Felder:

Beispiel:
StoreId<TAB>Amount<TAB>Notification<CRLF>
prod-1<TAB>25<TAB>10<CRLF>
prod-2<TAB>18<TAB>10<CRLF>

Kundenabhängige Preise

Anlegen und Ändern von kundenabhängigen Preisen (c-priceupdate.csv/c-pricecomplete.csv)

Diese beiden Dateien enthalten die kundenabhängigen Preise eines Subshops. Normalerweise werden sie zusammen mit den Produktdaten importiert, sie können jedoch auch unabhängig von diesen Dateien eingelesen werden.

Optional können mit dieser Datei auch die normalen, nicht kundenabhängigen Preise und Staffelpreise importiert werden. Dies kann sinnvoll sein, wenn das Auslesen der Preise aus dem exportierenden System sehr viel Zeit in Anspruch nimmt und es deshalb aus Performance-Gründen sinnvoll ist, geänderte Produktdaten ohne die zugehörigen (unveränderten) Preise zu importieren.

Beim Importieren der Datei c-priceupdate.csv werden nur die Preise aktualisiert, die in der Importdatei auftauchen, der Rest bleibt unverändert.

Beim Import einer c-pricecomplete.csv dagegen werden alle kundenabhängigen Preise gelöscht, die nicht in der Datei enthalten sind.

Die Dateien enthalten folgende Felder:

Allgemeine Bemerkungen

• Wenn für einen Artikel sowohl Preise für eine bestimmte Kundennummer als auch Preise für eine Preisgruppe angegeben sind: In diesem Fall werden die bei der Kundennummer angegebenen Preise verwendet, wenn sich ein Kunde einloggt, der die passende Kundennummer hat und zu der entsprechenden Preisgruppe gehört.

• Für jede Customer/Prodindex Kombination in der Datei sollte ein Eintrag mit Quantity=0 vorhanden sein.

• Wenn kundenabhängige Preise für abhängige Varianten importiert werden sollen, dann muss auch in der zugehörigen PRD-Datei ein Preis für die Varianten angegeben sein.

• Beim Löschen eines Produktes werden immer auch die (kundenabhängigen) Preise des Produkts gelöscht.

Bemerkungen zum optionalen Import von nicht kundenabhängigen Preisen

• Der Import von nicht kundenabhängigen Preisen über die c-price* Dateien muss von der WEBSALE AG freigeschaltet werden.

• Beim Import von nicht kundenabhängigen Preisen muss das Feld „Customer“ leer bleiben, für CustomerType muss der Wert „0“ übergeben werden.

Bemerkung zum Update vorhandener Preise

Für das Update gelten alle Felder außer „Price“ als Keyfelder, d.h. stimmen alle diese Felder mit einem bereits vorhandenen Eintrag in der Preistabelle überein, so wird der Preis aktualisiert, ansonsten wird ein neuer Eintrag in der Preistabelle angelegt.

Beispiel:
Eine c-pricecomplete.csv mit folgendem Inhalt wird importiert:

Danach wird eine c-priceupdate.csv mit diesem Inhalt importiert:

Dann hätte die Preistabelle des Shops danach den folgenden Inhalt:

Bei dem Eintrag mit Quantity „0“ wurde der Preis von 9.99 auf 10.00 geändert, weil die Importdatei eine Zeile enthielt, bei der ProdIndex, Quantity, Customer und CustomerType mit einem bereits in der Preistabelle vorhandenen Eintrag übereinstimmten.

Der Eintrag mit Quantity „5“ wurde neu in die Tabelle aufgenommen, weil kein passenden Eintrag gefunden wurde.

Der Eintrag mit Quantity „3“ schließlich blieb unverändert aus dem ersten Import erhalten.

Löschen von kundenabhängigen Preisen (c-pricedelete.csv)

Die c-pricedelete.csv Datei enthält die zu löschenden kundenabhängigen Preise.

Die Datei enthält folgende Felder:

Bemerkungen:
Ist das Feld „Customer“ leer, so werden alle Preise des angegebenen Produkts gelöscht, ansonsten nur die des zu Customer/CustomerType passenden Kunden.

• Beim Löschen der Preise für einen Kunden werden alle Staffelpreise für den Kunden gelöscht. Das explizite Löschen eines bestimmten Staffelpreises (z. B. den Preis für die Menge 5 des Kunden „abc“) ist nicht vorgesehen.

• Sollte in einer Importdatei sowohl eine Zeile mit leerem Customer-Feld als auch eine Zeile mit gefülltem Customer-Feld auftauchen, so werden alle Preise des Produktes gelöscht.

• Die c-pricedelete.csv wird vor der c-priceupdate.csv eingelesen, so dass Preise erst gelöscht und dann neu eingefügt werden können.

Online-Preise

„Online-Preise“ sind für Produkte gedacht, deren Preis sich häufig ändert. In den Importdateien wpupdate.csv bzw. wpcomplete.csv werden sie gekennzeichnet, in dem das Feld „OnlinePrice“ auf den Wert „y“ gesetzt wird.

Ähnlich zu den kundenabhängigen Preisen lassen sich die Online-Preise unabhängig von den restlichen Produktdaten importieren. Weiterhin werden die Preisänderungen, die während des Bestellablaufs auftreten, durch den Shop speziell behandelt.

Was den Import angeht, so gibt es folgende Unterschiede zwischen den „Online-Preisen“ und den „Kundenabhängigen Preisen“:

• Online-Preise können nicht kundenabhängig sein

• Es gibt keine Mengenabhängigkeit

• Statt des Produktindexes wird die Produktnummer zur Adressierung verwendet

Alle Importdateien für Online-Preise werden in dem Importverzeichnis des Subshops abgelegt.

Anlegen und Ändern von Online-Preisen
(onlinepriceupdate.csv/onlinepricecomplete.csv)

Beim Importieren der Datei onlinepriceupdate.csv werden nur die Preise aktualisiert die in der Importdatei auftauchen, der Rest bleibt unverändert.

Beim Import einer onlinepricecomplete.csv dagegen werden alle kundenabhängige Preise gelöscht, die nicht in der Datei enthalten sind.

Die Dateien enthalten folgende Felder:

Löschen von Online-Preisen (onlinepricedelete.csv)

Beim Importieren der onlinepricedelete.csv werden alle Online-Preise gelöscht, die in der Datei stehen.

Die Datei enthält folgendes Feld:

Bemerkungen:

• Ein implizites Löschen von Online-Preisen findet nicht statt, d.h. wenn ein Produkt über die wpdelete.csv aus dem Shop gelöscht wird, so bleiben die Online-Preise dennoch erhalten.

• Die Datei onlinepricedelete.csv wird vor den Dateien onlinepriceupdate.csv und onlinepricecomplete.csv eingelesen, so dass sich Preise bei einem Import löschen und wieder anlegen lassen.

Kombinationen für die abhängige Suche (depsearchcomplete.csv)

Hinweis: Es ist im allgemeinen nicht nötig die im folgenden beschriebene Importdatei zu generieren, wenn Sie die Funktion „abhängige Suche“ in Ihrem Shop nutzen wollen. Normalerweise genügt es, wenn Sie die freien Felder, die für die abhängige Suche verwendet werden sollen, im WSPManager konfigurieren und dann wie gewohnt nur die Produktdaten importieren.

Sie benötigen den Import der abhängigen Suche nur dann, wenn Sie selbst die möglichen Kombinationen von Feldwerten vorgeben wollen, die der Kunde im Shop auswählen kann.

Beispiel:
Sie bieten in Ihrem Shop Ersatzteile für Autos an, als freie Felder für die abhängige Suche verwenden Sie „Hersteller“ und „Modellreihe“. Ein bestimmtes Ersatzteil (z. B. eine Lampe) passt nun für die Hersteller/Modellreihen „Alfa Romeo“/„145“, „Alfa Romeo“/„146“, „Seat“/„Ibiza“ und „Seat“/„Malaga“.

Da in obigem Beispiel die Werte für die Lampe H4 im Feld Hersteller "Alfa Romeo, Seat" lauten und im Feld Modellreihe "145, 146", ist keine Zuordnung ersichtlich, welche Kombinationen von Hersteller und Modellreihe jeweils gültig sind. Wenn Sie nun dem Shop das Erzeugen der Auswahllisten überlassen, so würden, wenn Sie in der „Hersteller“-Listbox den Wert „Alfa Romeo“ auswählen in der „Modellreihe“-Listbox aufgrund der fehlenden Zuordnung die Werte „145“, „146“, „Ibiza“ und „Malaga“ angezeigt.

Wenn Sie nun wollen, dass bei der Auswahl von „Seat“ nur die zu dieser Marke passenden Modellreihen („Ibiza“ und „Malaga“) angezeigt werden, so müssen Sie die zulässigen Kombinationen selbst importieren.

Aufbau der Importdatei

Im Gegensatz zu den meisten anderen Importdateien sind die Feldnamen dieser Datei nicht fest vorgegeben. Die Spaltenüberschriften entsprechen vielmehr den technischen Feldnamen der freien Felder, die für die abhängige Suche verwendet werden sollen.

Beispiel:
Die Importdatei für das obige Beispiel könnte folgendermaßen aussehen:
Hersteller<TAB>Modellreihe
Alfa Romeo<TAB>145
Alfa Romeo<TAB>146
Seat<TAB>Ibiza
Seat<TAB>Malaga

Aktivierung des Imports im WSPManager

Der WSPManager muss wissen, ob die Kombinationsmöglichkeiten automatisch ermittelt werden sollen oder ob Sie die Kombinationsmöglichkeiten importieren wollen. Aus diesem Grund müssen Sie, wenn Sie den Import verwenden wollen, im WSPManager unter „Shopeinstellungen“/„Divers“ die Checkbox „Abhängige Suche“/„Import der zulässigen Kombinationen“ anhaken.

Bemerkung
Auch wenn Sie die Importfunktion für die Kombinationsmöglichkeit verwenden, so müssen Sie dennoch die zugehörigen Werte der freien Felder in den Produktdaten importieren, ansonsten werden Produkte im Shop nicht gefunden!

Beachten Sie, dass Sie in die freien Felder auch (kommagetrennte) Listen von Werten eintragen können, sodass ein Produkt bei mehreren verschiedenen Suchbegriffen gefunden wird (in dem obigen Beispiel wird die Lampe z. B. bei Suche nach „Alfa Romeo“ und bei der Suche nach „Seat“ gefunden).

Produktabhängige Versandkosten (deliveryupdate.csv/deliverydelete.csv)

Mit Hilfe dieser beiden Importdateien ist es möglich Ihre Versandkosten von WEBSALE produktgenau berechnen zu lassen.

Die Berechnung bezieht sich dabei auf:

• Die Bestellmenge einer Versandkostengruppe oder Artikelnummer

• Die Versandkostenart (länderabhängig und lieferantenabhängig)

• Die PLZ des Empfängers (optional)

Aufbau der Datei deliveryupdate.csv

Aufbau der Datei deliverydelete.csv

Die Datei enthält folgende Felder:

Rabattgruppen (discount.csv)

Mit Hilfe von Rabattgruppen lassen sich (Gruppen von) Produkten mengen- oder preisabhängige Rabatte zuordnen. Optional können diese Rabatte zusätzlich kundenabhängig gestaltet werden.

Die zugehörigen Dateien werden im Import-Verzeichnis des Shops oder des Subshops abgelegt. Liegt die Datei im Import-Verzeichnis des Shops, so gilt sie für alle Subshops. Liegt sie im Verzeichnis eines Subshops, so gilt sie nur für diesen Subshop. Liegt sowohl im Shop-Verzeichnis als auch im Subshop-Verzeichnis eine discount.csv, so wird die Subshop-Datei verwendet.

Kundenunabhängige Rabattgruppen (discount.csv)

Die Einträge dieser Datei werden vom Shop von oben nach unten gelesen, der letzte passende Eintrag legt den zu verwendenden Rabatt fest.

Dies bedeutet speziell, dass Zeilen mit höheren „Amount“-Werten unterhalb von Zeilen mit niedrigerem Amount geschrieben werden müssen. Analog müssen Zeilen in denen die Felder ValidFrom oder ValidUntil gefüllt sind unterhalb von Zeilen stehen, bei denen diese Felder nicht gefüllt sind.

Kundenabhängige Rabattgruppen
Wollen Sie je nachdem welcher Kunde sich eingeloggt hat unterschiedliche Rabatte anbieten, so müssen Sie je (Kunden-)Rabattgruppe eine eigene Datei generieren.

Der Name der Datei ist „discount_“ + Kunden-Rabattgruppe + “.csv“. Haben Sie z. B. in den Kundendaten die Kunden-Rabattgruppe „abc“ verwendet, dann würde die Datei „discount_abc.csv “ heißen.

Wie Sie Kunden einer Kunden-Rabattgruppe zuweisen, ist in der Dokumentation „Kundendaten PRO“ erläutert (siehe ).

Der Aufbau der Dateien für kundenabhängige Rabattgruppen ist identisch zum Aufbau der kundenunabhängigen Dateien, ebenso das Verzeichnis.

Löschen von Rabattgruppen-Dateien
Einmal importierte Dateien lassen sich nicht mehr löschen. Sie können sie jedoch durch leere Dateien bzw. Dateien, die nur eine Header-Zeile enthalten, überschreiben.

Kundenabhängige Produktnummern

Anlegen und Ändern von kundenabhängige Produktnummern (custpnumbersupdate.csv/custpnumberscomplete.csv)

Mit Hilfe von kundenabhängigen Produktnummern lässt sich erreichen, dass im Shop für angemeldete Kunden, kundenabhängige Produktnummern angezeigt werden, die von den Produktnummern in den Produktdaten abweichen.

Beim Importieren der Datei custpnumbersupdate.csv werden nur die Produktnummern aktualisiert oder angelegt die in der Importdatei stehen, der Rest bleibt unverändert.
Beim Import einer custpnumberscomplete.csv dagegen werden alle kundenabhängige Produktnummern gelöscht die nicht in der Datei enthalten sind.

Die Dateien enthalten folgende Felder:

Beispiel:
CustomerNumber<TAB>OrigProductNumber<TAB>CustomerProductNumber
12345671<TAB>1112223331<TAB>111a
12345671<TAB>1112223332<TAB>111b
12345671<TAB>1112223333<TAB>111c
12345672<TAB>1112223331<TAB>11133a
12345672<TAB>1112223332<TAB>11133b

Bemerkungen:

• Je Kundennummer und je Original-Produktnummer (OrigProductNumber) kann nur eine kundenabhängige Produktnummer (CustomerProductNumber) importiert werden. Befinden sich mehrere Zeilen für den gleichen Kunden und das gleiche Produkt in der Importdatei, so wird nur die letzte Zeile übernommen.

• Die kundenabhängigen Produktnummern müssen zusätzlich im Feld „CustomerProductNumbers“ in den Produktdaten (wpupdate.csv/wpcomplete.csv) importiert werden.

Löschen von kundenabhängige Produktnummern (custpnumbersdelete.csv)

Mit der Datei „custpnumbersdelete.csv“ lassen sich Einträge die mit den Dateien „custpnumbersupdate.csv“ oder „custpnumberscomplete.csv“ angelegt wurden wieder löschen.

Die Datei enthält folgende Felder:

Beispiel:
CustomerNumber<TAB>OrigProductNumber
12345671<TAB>1112223331
12345672<TAB>*
*<TAB>1112223332
Bemerkungen:

• Steht für CustomerNumber ein „*“ in der Datei, so werden alle im Shop gespeicherten Einträge mit der angegebenen OrigProductNumber gelöscht.

• Steht für OrigProductNumber ein „*“ in der Datei, so werden alle im Shop gespeicherten Einträge mit der angegebenen CustomerNumber gelöscht.

• Wird ein Kunde oder ein Produkt aus dem Shop gelöscht, so werden die zugehörigen kundenabhängigen Produktnummern nicht automatisch gelöscht.

Diverse Shop-Parameter (parameter.ini)

Für Parameter, die den Import betreffen, aber in keine der anderen Importdateien passen, gibt es die Importdatei „parameter.ini“. Die in diesem Abschnitt beschriebene Datei enthält Einstellungen, die alle Subshops betreffen (siehe auch "Diverse Subshop-Parameter").

Der Aufbau der Datei entspricht den übrigen „INI“-Dateien des Shops, d.h. sie ist in Sektionen gegliedert, die Name/Wert-Parameter enthalten:

Einzige gültige Sektion ist derzeit „Inventory“, der einzige gültige Parameter „ValidDateTime“. Dieser Parameter gibt an, auf welchen Zeitpunkt sich die importierten Lagerbestandsdaten beziehen.

Das Format des Parameters ist YYYYMMDDhhmmss also z. B. „20060523163310“.

Hintergrund für diesen Parameter ist, dass die Erstellung der Lagerbestandsimportdatei, der Import und die Übertragung dieser Daten mehr oder weniger viel Zeit in Anspruch nehmen. Während dieses Vorgangs können weiterhin Bestellungen eingehen, so dass der schließlich gesetzte Bestand vom tatsächlich vorhandenen abweichen kann.

Beispiel: Um 14:05 wird die amount.dat erstellt, für das Produkt xyz sind zu diesem Zeitpunkt noch 5 Stück auf Lager, tatsächlich im Online-Shop gesetzt wird der Bestand für das Produkt aber erst um 14:15. Um 14:13 bestellt ein Kunde 4 Stück des Produkts, wenn der Bestand „normal“, d.h. ohne Angabe von ValidDateTime importiert wird, dann wären jetzt im Shop 5 Stück verfügbar, obwohl (nach Auslieferung der Bestellung von 14:13) nur noch ein Stück auf Lager ist.

Würde in dem obigen Beispiel „20090728140500“ als „ValidDateTime“ übergeben werden, dann würden beim Setzen des Bestandes um 14:15 alle zwischen 14:05 und 14:15 eingegangenen Bestellungen vom Bestand abgezogen und der Bestand also auf den korrekten Wert „1“ gesetzt werden.

Damit die Funktion im Shop verwendet werden kann muss in der shop.config der entsprechenden Subshops im Abschnitt <Inventory> der Parameter „SetOrderInventory-Allow“ auf „yes“ gesetzt werden.

Diverse Subshop-Parameter (parameter.ini)

Für Parameter, die den Import betreffen, aber in keine der anderen Importdateien passen, gibt es die Importdatei „parameter.ini“. Die in diesem Abschnitt beschriebene Datei enthält Einstellungen die einen bestimmten Subshop betreffen (siehe auch "Diverse Shop-Parameter").

Der Aufbau der Datei entspricht dem der übrigen „INI“ Dateien des Shops, d.h. sie ist in Sektionen gegliedert, die Name-/Wert-Parameter enthalten:

Sektion <Options>

In der Sektion „Options“ ist derzeit der einzige gültige Parameter „PreserveFields“. Dieser Parameter kann eine kommagetrennte Liste von Feldern enthalten, die beim Import nicht überschrieben werden soll.

Beachten Sie, dass diese Option nur für Felder funktioniert, die nicht für Suche, Filter, Sortierung oder ähnliche Funktionen benutzt werden.

Sektion <ProductFields>

Die Sektion „ProductFields“ enthält Eigenschaften von Produktdaten-Feldern, die über den Import gesetzt werden können. Für jedes Produktdaten-Feld für das Eigenschaften importierten werden sollen muss die Sektion „ProductFields“ eine Untersektion „Field“ enthalten.

Beispiel:

Die Sektion „Field“ kann folgende Parameter enthalten:

Bemerkungen:

• Wird bei einem Import keine parameter.ini geliefert, so bleiben die vorhandenen Feldeinstellungen unverändert.

• Damit die unter „FilterSortSelect“ angegebene Sortierung verwendet wird muss unter „Einstellungen für Filterlistboxen“ (im WSPManager) für das zu sortierende Feld die Sortierung „Liste“ eingestellt sein.

Spezielle Themen

„Happy Hour“ Produkte

Für Produkte in der „Happy Hour“ Kategorie ist eine Zeitsteuerung aktiv, die dafür sorgt, dass immer nur ein Teil der Produkte im Shop sichtbar ist. Weiterhin kann für die gerade in der Kategorie sichtbaren Produkte ein „Happy Hour“ Rabatt gewährt werden.

Produkte werden in die „Happy Hour“ Kategorie importiert, in dem sie in der catupdate.csv/catcomplete.csv Datei der Kategorie „happyhour“ zugewiesen werden, weiterhin muss in der Datei wpupdate.csv/wpcomplete.csv das Feld „Event“ auf den Wert „y“ gesetzt werden.

Mit den optionalen Feldern „EventProductNumber“ und „EventDiscount“ kann eine abweichende Produktnummer und ein Rabatt angegeben werden die verwendet werden, wenn das Produkt in der „Happy Hour“ Kategorie angezeigt wird.

Die Einstellungen der „Happy Hour“ Kategorie selbst können beim Import der Datei catcomplete.xml geändert werden („eventrotationtime“ und „eventproducts“).

„Happy Hour“-Kategorie

Die Einstellungen der „Happy Hour“ Kategorie können zusammen mit den übrigen Kategoriedaten in der catcomplete.xml importiert werden.

"eventrotationtime" gibt die Zahl der Stunden an nach den die Produkte rotiert werden sollen, "eventproducts" die Zahl der gleichzeitig sichtbaren Produkte.

Beachten Sie, dass die Kategorie im Abschnitt "nomenucategories" steht und das die Attribute "index" und "type" die Werte "happyhour" bzw. "event" haben.

Warenkorb Kategorie

Artikel, die der „Warenkorb“ Kategorie zugewiesen sind, werden beim Bestellvorgang automatisch dem Warenkorb hinzugefügt.

Produkte werden in die „Warenkorb“ Kategorie importiert, indem sie in der catupdate.csv/catcomplete.csv Datei der Kategorie „autobasket“ zugewiesen werden.

Für die Produkte gelten folgende Einschränkungen:

• Der Preis muss 0.00 sein.

• Es sollten bei der Bestellung keine Eingaben nötig sein, d. h. das Produkt darf keine Varianten oder Texteingabefelder haben.

• Es können maximal 3 Produkte zur „Warenkorb“ Kategorie zugewiesen werden.

Da die Warenkorb Kategorie keine Einstellungen wie Templates oder Beschreibung unterstützt und prinzipiell nicht im Shopmenü angezeigt wird braucht sie auch nicht in die catcomplete.xml geschrieben zu werden.

Der optionale Mindestbestellwert, ab dem ein Produkt in den Warenkorb gelegt wird, kann über das Feld „ABMinOrderVal“ in der Datei wpupdate.csv/wpcomplete.csv importiert werden.

Mehrfachbilder

Es besteht die Möglichkeit, im Onlineshop zusätzlich zu den normalen Bildern sogenannte „Mehrfachbilder“ anzeigen. Bei der Anzeige eines Produkts werden diese Bilder zunächst als Minibild dargestellt, beim Klick auf eines dieser Minibilder wird es in normaler Größe angezeigt und ersetzt dabei das ursprüngliche Bild.

Im WSPManager muss für jedes Mehrfachbild und für jede Bildgröße ein freies Feld angelegt werden. Wenn z. B. (zusätzlich zu dem normalen Bild) drei Mehrfachbilder angezeigt werden sollen, dann müssten die Felder

Bild_mini_1
Bild_mini_2
Bild_mini_3
Bild_klein_1
Bild_klein_2
Bild_klein_3
Bild_mittel_1
Bild_mittel_2
Bild_mittel_3
Bild_gross_1
Bild_gross_2
Bild_gross_3

angelegt werden.

Der Typ der freien Felder muss dabei auf "Medien Bild mini", "Medien Bild klein", "Medien Bild normal" und "Medien Bild gross" gesetzt werden, jeweils entsprechend der Größe des Bildes.

Die Bilddateien werden wie die normalen Produktbilder in den Verzeichnissen ".../produkte/medien/bilder/mini", ".../produkte/medien/bilder/klein", ".../produkte/medien/bilder/normal" und ".../produkte/medien/bilder/gross" abgelegt.

In den freien Feldern selbst steht dann nur noch der Bildname ohne Pfad.

Wenn für ein Produkt weniger als (in diesem Beispiel) drei Mehrfachbilder angezeigt werden soll, so werden die überschüssigen Feldnamen einfach leer gelassen.

Nicht mehr existierende Produkte/nicht mehr existierende Kategorien

„Nicht mehr existierende Produkte“ und „Nicht mehr existierende Kategorien“ sind Verfahren zur „Link-Rettung“ von gelöschten Produkten und Kategorien: Mit ihnen wird vermieden, dass Links auf Produkte oder Kategorien „ins Leere“ gehen, wenn Produkte oder Kategorien gelöscht werden.

Stattdessen können Aufrufe von gelöschten Produkten oder Kategorien mit diesen Techniken auf andere Produkte oder Kategorien umgeleitet werden.

Um die Funktion „Nicht mehr existierende Produkte“ zu nutzen müssen Sie beim Import das „Discontinued“ Feld in den Importdaten mit dem Wert „y“ importieren. Das Produkt wird dann aus dem Shop gelöscht und Aufrufe des Produkts auf die Kategorie umgeleitet, in der das Produkt stand.

Alternativ haben Sie die Möglichkeit im Feld „DiscontinuedSubstitute“ den Produktindex eines Ersatzproduktes anzugeben, auf das Aufrufe umgeleitet werden sollen.

Ein Produkt braucht und sollte nur einmal als „Discontinued“ importiert werden, beachten Sie, dass dabei noch einmal sämtliche Produktdaten (einschließlich eventuell vorhandener Varianten und Zuordnungen zu Kategorien) geliefert werden müssen.

Für die Funktion „Nicht mehr existierende Kategorien“ brauchen sie an den Importdaten nichts zu ändern, sie muss nur von der WEBSALE AG für Ihren Shop aktiviert werden.

Ein Aufruf einer gelöschten Kategorie wird auf die nächste Kategorie umgeleitet, die in der Hirarchie über der gelöschten Kategorie steht und die noch existiert.

Sowohl die Funktion „Nicht mehr existierende Produkte“ als auch die Funktion „Nicht mehr existierende Kategorien “ müssen von der WEBSALE AG freigeschaltet werden.

Service-Produkte

„Service-Produkte“ sind Produkte, die sich im Shop nicht mehr bestellen lassen und die keiner Kategorie mehr zugeordnet sind, die aber noch über die Suche gefunden werden und über Deep-Links aufgerufen werden können.

Der Zweck von „Service-Produkten“ ist es, den Kunden auch dann noch Informationen (z. B. technische Daten, Download von Handbüchern) zu den Produkten zur Verfügung stellen, wenn sie im Shop nicht mehr verkauft werden.

„Service-Produkte“ werden importiert, in dem das Feld „Service“ in den Importdaten auf den Wert „y“ gesetzt wird. Es müssen dabei nochmal alle Daten geliefert werden, die für das Service Produkt im Shop angezeigt werden sollen.

Eine Zuordnung eines Service Produkts zu einer Kategorie ist nicht nötig bzw. nicht zulässig.

Es genügt ein Service-Produkt einmalig zu importieren, Service-Produkte bleiben auch bei Komplett-Importen im Shop erhalten, wenn für sie keine Importdaten geliefert werden.

Soll ein Service-Produkt gelöscht werden, so muss dies explizit über die Importdatei wpdelete.csv erfolgen.

Die Funktion „Service-Produkte“ kann mit der Funktion „Nicht mehr existierende Produkte“ kombiniert werden. Beachten Sie, dass in diesem Fall aber der Produkt-Index des Produkts umbenannt wird, in dem der Präfix „sp_“ vorangestellt wird.

Diese Umbenennung ist nötig, da ansonsten ein Deep-Link auf das Service Produkt auf die Ersatzkategorie bzw. das Ersatzprodukt umgeleitet werden würde.

Wenn ein Produkt gleichzeitig „Service-Produkt“ und „discontinued“ sein soll, so müssen die Felder „Service“ und „Discontinued“ auch gleichzeitig gesetzt werden. D. h., es ist nicht möglich, ein Produkt als „Service-Produkt“ zu importieren und bei einem späteren Import auf „discontinued“ zu setzen (oder umgekehrt). Beide Flags müssen bei dem gleichen Import gesetzt werden.

Die Funktion „Service-Produkte“ muss von der WEBSALE AG freigeschaltet werden.

Günstigste zeitabhängige Preise (BestPrices)

In dem Feld “Bestprice” (das den günstigsten Preis für ein Produkte mit Varianten enthält) kann keine Zeitabhängigkeit angegeben werden. Wenn in einem Shop zeitabhängige Preise verwendet werden und diese Zeitabhängigkeit auch bei der Ermittlung des günstigsten Preises berücksichtigt werden soll, so kann beim Import optional das Feld “BestPrices” generiert werden.

Dazu muss in der global.config der Parameter “CreateBestPrices” eingefügt werden:

Es wird dann aus den Feldern “AltPrices” und “Price“ in den PRD-Dateien das Feld “BestPrices” generiert, aus dem der Shop für jeden Zeitpunkt den jeweils günstigsten Preis ermitteln kann.
Die eigentlichen Importdaten brauchen nicht verändert zu werden.

Da dies ein zeitaufwändiger Prozess ist, der die Laufzeit des Imports verlängert, sollte das Feature nur aktiviert werden, wenn es tatsächlich benötigt wird.

Schutz vor leeren Importen

In der Datei global.config im Verzeichnis „konfiguration“ des Shops können minimale Werte für die Anzahl der Kategorien und der (Kategorien zugewiesenen) Produkte konfiguriert werden:

Vor dem Start des Imports wird für jeden Subshop geprüft, ob die angegebenen Zahlen nach dem Import voraussichtlich unterschritten werden. Wenn ja, dann wird der Import für den Subshop abgebrochen bzw. erst gar nicht gestartet.

Bei diesem Vorab-Check werden nur die Dateien „catcomplete.xml“, „catcomplete.csv“ und „wpcomplete.csv“ geprüft. D.h. bei Delta-Importen greift die Funktion nicht.

Zweck des Features ist es zu verhindern, dass der Shop leer ist, wenn durch ein Versehen unvollständige Daten importiert werden.

Beispiel-Dateien

Folgende ZIP-Verzeichnisse mit Beispieldateien sind Teil dieser Dokumentation, die Sie auf der untergeordneten Seite zum Download finden: