Format und Inhalt - WS-SFTP-Kunden PRO (DE)
- René Meyer
- Harald Brinck
- Rainer Biedermann
- David Kern (Deactivated)
Allgemeines
Diese Dokumentation beschreibt das Format und den Inhalt der Importdateien um Kundenstammdaten in den Shop zu senden.
Übertragung der Importdateien
Die nachfolgend beschriebenen Importdateien können dabei auf 3 Arten übertragen werden.
Übertragung per SFTP/REST
Schritt 1: Übertragen der Importdateien mittels SFTP
Schritt 2: Starten des Imports der Daten mittels REST-Trigger
Da das Triggerverfahren in ähnlicher Weise für verschiedene Schnittstellen verwendet wird, ist es in der separaten Dokumentation „SFTP-REST-to-Shop“ beschrieben.
Übertragung per SFTP/SOAP
Schritt 1: Übertragen der Importdateien mittels SFTP
Schritt 2: Starten des Imports der Daten mittels SOAP-Trigger
Da das Triggerverfahren in ähnlicher Weise für verschiedene Schnittstellen verwendet wird, ist es in der separaten Dokumentation „SFTP-SOAP-to-Shop“ beschrieben.
Alternative Übertragung per WSPManager (Vorgängerversion)
Auch mittels des von WEBSALE bereitgestellten Windows-Tools „WSPManager“ können Daten auf den Shop-Server übertragen und importiert werden. Diese Methode sollte benutzt werden, wenn z. B. auf dem System des Händlers kein SFTP-Transfer bzw. kein REST/SOAP-Trigger implementiert werden kann.
Die Übertragung per WSPManager wird in der separaten Dokumentation „WSPManager-to-Shop“ beschrieben.
Format und Zeichensatz der Dateien
Die Importdateien müssen im CSV-Format (character separated values) geliefert werden.
Das Zeichen (Character) das als Feld-Trennzeichen verwendet wird, muss das Tabulator-Zeichen (ASCII 9) sein. Andere Feldtrenner sind nicht zulässig.
Durch die Verwendung des Tabulator-Trennzeichens ist eine zusätzliche Umkleidung von Textfeldern, z. B. durch Doppel-Anführungszeichen ("), nicht erforderlich und auch nicht zulässig. Alle Arten von Anführungszeichen sind reguläre, zulässige Zeichen in den Feldern und dürfen daher direkt und ohne weitere Markierung in den Daten enthalten sein.
Der Zeichensatz in dem die Daten codiert sind, richtet sich nach der Sprache des Landes für den der Shop betrieben wird. Es sind die im Internet normierten Länder- ISO-Codes (z. B. ISO 8859-1) zu verwenden. Die Verwendung von UTF-8 ist bei WEBSALE V8 nicht zulässig, da sonst viele Schnittstellen und Services intern und zu Drittanbietern fehlerhafte Ergebnisse liefern würden.
Adressierung der Datensätze
Um gezielt auf die Stammdaten eines Kunden zugreifen zu können, sind Schlüsselfelder in den Daten erforderlich. Hierbei gibt es verschiedene Schlüsselfelder deren Inhalt entweder der Shop, die Warenwirtschaft oder der Kunde verwaltet.
Zu jedem Kundendatensatz gehören nur ein Mal vorkommende Daten wie der Kundenname oder dessen Anschrift, aber auch mehrfach vorkommende Datensets (Multiple Kundenzusatzdaten) wie mehrere abweichende Lieferanschriften.
IDs mit Schlüsselfunktion
Die primäre Identifikation eines Kunden erfolgt im Shop stets über seine Mail-Adresse.
Ein Neukunde ist aus Sicht des Shops somit ein Kunde, der sich im Shop ein neues Konto anlegt mit einer neuen, d. h. bisher noch keinem Konto zugeordneten, E-Mail-Adresse.
UserIndex der Kundenstammdaten (vom Shop verwaltet)
Der UserIndex ist eine eindeutige, numerische ID, die ausschließlich vom Shop bei einer Neuanlage eines Kundendatensatzes in der Shop-Datenbank vergeben wird.
Mögliche Fälle der Neuanlage im Shop
Ein Neukunde registriert sich im Shop
Ein ERP-System übergibt an den Shop einen bisher im Shopsystem unbekannten Kundendatensatz.
Um vorhandene Datensätze im Shop zu aktualisieren adressiert ein ERP-System einen Kundendatensatz mittels UserIndex.
CustomerID der Kundenstammdaten (vom ERP verwaltet)
Die CustomerID ist aus Sicht des Shops lediglich ein String, den der Shopbetreiber vergeben hat. Üblicherweise ist die CustomerID die eindeutige Kundennummer die das ERP-System generiert hat und mit dem im ERP-System der Kunden referenziert wird.
Importiert ein ERP-System einen neuen Kundendatensatz aus dem Shopsystem und vergibt anschließend eine neue Kundennummer (CustomerID), so muss das ERP-System dem Shop diese neue Kundennummer mitteilen. Als Userindex muss in dem Fall der Wert übergeben werden, der dem ERP zusammen mit der Bestellung oder dem Kundendatensatz (beim Abholen von Kundendatenänderungen) übermittelt wurde. Existiert bereits eine gleiche Kundennummer im Shop, dann wird der Import als Dublette abgelehnt.
TableIndex und ExternalID der Multiplen Kundenzusatzdaten
Diese beiden IDs werden bei der Adressierung in Tabellen von sog. "Multiplen Kundenzusatzdaten" verwendet, d. h. bei Datensätzen die nicht nur ein Mal sondern auch mehrfach vorkommen können. Solche multiplen, auch mehrfach je Kunde vorkommenden Datensätze können bei 2 Datentypen vorkommen
Lieferadressen
Bankverbindungen
Für jeden dieser zwei Datentyp gibt es im Shop eine eigene Tabelle.
TableIndex
Der TableIndex wird ausschliesslich vom Shop bei einer Neuanlage eines Datensatzes in einer der Kundenzusatzdaten-Tabellen vergeben.
Der TableIndex ist eine innerhalb der Tabelle eindeutige numerische ID.
Da es sich um drei verschiedene Kundenzusatzdaten-Tabellen handelt, können und werden in jeder Tabelle die TableIndex-Werte für die darin befindlichen Datensätze teilweise auch gleiche Werte aufweisen.
Beispiel
Ein Datensatz in der Tabelle der Lieferadressen kann den TableIndex "123" aufweisen, ebenso wie ein Datensatz eines ganz anderen Kunden in der Tabelle der Bankverbindungen ebenfalls den TableIndex "123" haben kann.
ExternalID
Die ExternalID ist aus Sicht des Shops lediglich ein String, den der Shopbetreiber vergeben hat. Üblicherweise ist dies ein Index den das ERP-System generiert hat und mit dem im ERP-System z. B. eine vom mehreren (multiplen) Lieferadressen eines Kunden referenziert wird.
Regeln der Datenübergabe vom ERP an den Shop
Neuanlage eines Kundenstammdatensatzes
Ein ERP-System übergibt an das Shopsystem einen Datensatz mit vom ERP vergebener neuer CustomerID und einer im Shop noch nicht bekannten Mail-Adresse.
Das Kennzeichen einer Neuanlage ist, dass das Feld "UserIndex" in den Kundenstammdaten leer ist.
Im Zuge des Imports der neuen Kundenstammdaten in die Shopdatenbank wird der UserIndex neu vergeben und anschließend vom Shop über eine Export-Schnittstelle an das ERP-System mitgeteilt (siehe Dokumentation der Schnittstelle „SOAP-from-shop“).
Der Import einer Kundendatensatz-Dublette wird als Fehler abgelehnt und der Datensatz wird verworfen. Eine Dublette wird erkannt, wenn in der Shopdatenbank die CustomerID oder die Mail-Adresse bereits vorhanden ist. Sowohl CustomerID als auch Mail-Adresse dürfen also im Shop nicht vorhanden sein. Die übrigen Daten wie Name oder Anschrift spielen für die Dublettenprüfung des Shops beim Kundendatenimport keine Rolle!
Hinweis:
Bei einem B2B-Shop könnte es eventuell eine Ausnahme von der Regel "Neuanlage nur bei nicht vorhandener Mail-Adresse" geben. Und zwar bei Verwendung sog. "Mehrfachkonten" (siehe dazu weiter unten das Kapitel "Mehrfachkonten"). In dieser Dokumentation wird jedoch im Zusammenhang mit der Mailadresse stets der Standardfall "eine Mailadresse darf nur ein Mal vorhanden sein" behandelt.
Update eines Kundenstammdatensatzes
Ein ERP-System aktualisiert einen bereits im Shop vorhandenen Datensatz, indem sämtliche Felder des gewünschten Kundenstammdatensatzes übergeben werden.
Das Kennzeichen eines Updates ist, dass das Feld "UserIndex" einen im Shop vorhandenen UserIndex beinhaltet.
Neuanlage eines Multiplen Kundenzusatzdatensatzes
Bei einer Neuanlage können dem Shop gleiche E-Mail-Adressen für unterschiedliche Konten übergeben werden. Die CustomerID muss jedoch eindeutig sein und darf noch nicht im Shop existieren. Sollte die CustomerID bereits existieren, so wird der Datensatz verworfen.
Update eines Multiplen Kundenzusatzdatensatzes
Ein Update eines multiplen Kundendatensatzes erfolgt über den UserIndex, wie es im Abschnitt oben “Update eines Kundenstammdatensatzes” beschrieben ist.
Beispiele der Adressierung
Zuweisung der IDs von Neukunden, die sich selbst im Shop registrieren
In der Shopdatenbank wird bei der Neuanlage des Kundenstammdatensatzes ein neuer UserIndex, z. B. „123456“generiert .
Der Shop übergibt nach der Neuanlage diesen UserIndex zusammen mit den anderen Kundenstammdaten an das ERP-System.
Die Übergabe der Kundenstammdaten des Neukunden erfolgt nach seiner Registrierung. Es werden dabei zwei Fälle unterschieden:
Übergabe gemeinsam mit den Bestelldaten
wenn der Kunde nach der Neuanlage des Kontos eine Bestellung aufgegeben hatÜbergabe per Adressänderungsdaten
wenn der Kunde nach der Neuanlage des Kontos nichts bestellt hat
Bei der Übergabe der Kundenstammdaten bleibt das Feld CustomerID (Kundennummer) leer, da der Shop ja noch keine ERP-Kundennummer kennt (siehe Dokumentation der Schnittstelle „SOAP-from-Shop“).
Das ERP-System muss nun beim Einlesen der Bestellung bzw. Adressänderungsdaten das Feld CustomerID prüfen und aufgrund der nicht vorhandenen Kundennummer erkennen, dass es sich um einen neuen Shopkunden handelt. Es muss dann eine neue ERP-Kundennummer vergeben, z. B. „777888“. Diese wird umgehend an den Shop zurück repliziert, indem das ERP-System in der Importdatei den Kunden mit dem Shop-UserIndex „123456“ adressiert und die neu vergebene ERP-Kundennummer „777888“ übergibt.
Zuweisung der IDs von Neukunden, die im ERP-System angelegt werden
Im ERP-System wird ein neuer Kunde (z. B. durch Mitarbeiter im Callcenter des Händlers) angelegt.
Für den Import eines Neukunden in den Shop sind mindestens 2 Felder notwendig:
eine neue Kundennummer
eine neue Mail-Adresse
Beide Felder sind Pflichtfelder. Der UserIndex hingegen muss in diesem Fall leer oder 0 sein.
Der Shop erkennt aufgrund des fehlenden UserIndex, dass es sich um eine Neuanlage handeln soll und prüft, ob CustomerID oder E-Mail bereits existieren. Falls nicht, wird ein neuer Datensatz mit einem neuen UserIndex in der Shopdatenbank angelegt. Die Userindizes der angelegten Neukunden lassen sich über die SOAP-Funktion “GetAddedCustomers” abfragen (siehe Dokumentation Übertragung per SFTP-SOAP-to-Shop).
Ausnahmen und Optionen
eMarketingManager-Anlagen
Neben dem Shop, legt auch der WEBSALE-eMarketingManager (eMM), ein Newslettersystem mit erweitertem Funktionsumfang, Datensätze an. Diese sind
Mail-Adresse
optionale Adressdaten
Da für einen Newsletter meist nur die Angabe einer Mail-Adresse erforderlich ist, sind die vom eMarketingManager (eMM) angelegten Kundendatensätze üblicherweise ohne Passwort.
Als Folge davon dass ein ERP-System einen Kundendatensatz aus dem Shop, der allein aus einer Mail-Adresse besteht, in der Regel verwirft, hat der Datensatz auch keine Kundennummer in der Kundendatenbank.
Hierbei ist zu beachten, wenn später ein Datensatz aus dem ERP-System mit einer vom der gleichen Mail-Adresse importiert werden soll:
Viele ERP-Systeme kennen den UserIndex dieser Datensätze nicht, da sie entweder keine Adressdatenänderungen aus dem Shop einlesen oder die unvollständigen Adressdaten, die der eMarketingManager anlegt verworfen haben.
Wenn diese Systeme dann versuchen einen neuen Datensatz mit der gleichen Mail-Adresse anzulegen, so wird dieser beim Import mit einer Fehlermeldung abgewiesen, da eine Mail-Adresse nicht doppelt in der Datenbank vorkommen darf.
Aus diesem Grund wird unter folgenden Bedingung zusätzlich die Mail-Adresse zu Adressierung herangezogen:
In den Importdaten vom ERP ist kein UserIndex angegeben (d. h. es handelt sich aus Sicht des ERP um die Anlage eines Neukunden)
In der Shop-Kundendatenbank existiert ein Kunde mit der Mail-Adresse in den Importdaten und ohne angelegtes Passwort und ohne Kundennummer in der Shopdatenbank.
Wenn diese Bedingungen erfüllt sind, so werden die Kundendaten aus den Importdaten in den Shop-Datensatz geschrieben, der die angegebene Mail-Adresse hat.
Hinweis:
Dies ist auch unter Datensicherheits-Aspekten aus Sicht des Shops tolerierbar, denn der Besitzer der Mailadresse musste sich bei der Newsletter-Registrierung einem Double-Opt-In-Verfahren unterziehen und damit eindeutig die Berechtigung zur Nutzung der Mail-Adresse beweisen.
Mehrfachkonten (eMail)
Mehrfachkonten sind ein Feature das vom Versandhändler für einen B2B Shop gewünscht sein kann.
Standardmäßig kann in einem WEBSALE Shop je Mail-Adresse immer nur ein einziges Konto angelegt werden. Sind jedoch in einem Shop Mehrfachkonten erlaubt, so ist es möglich, abweichend vom Standard, mehrere Kundenkonten mit der gleichen Mail-Adresse anzulegen. Jedes dieser Mehrfachkonten hat dann ein eigenes Passwort für den Login.
Mehrfachkonten sollten in einem Shop nur in absoluten Ausnahmefällen eingesetzt werden, da Mail-Dubletten einige Funktionen im Shop einschränken oder gar unmöglich machen.
Beispiel für eine Anwendung
Eine Einkaufsabteilung mit mehreren Einkäufern wickelt nicht mit individuellen Mail-Adressen je Einkäufer sondern mit einer einzigen zentralen Einkaufs-Mail-Adresse (z. B. einkaufsteam@firma.de) sämtliche einkaufsbezogene Kommunikation ab. Dennoch soll aber jede Bestellung im Shop nachvollziehbar dem einzelnen Einkäufer zugeordnet werden. In diesem Fall findet das Login in den Shop mit der jeweils gleichen Mail-Adresse statt, jeder Einkäufer hat aber sein eigenes Passwort. Durch die Kombination Mail / Passwort wird die Zuordnung zum richtigen Stammdatensatz des jeweiligen Einkäufers gewährleistet.
Bei Mehrfachkonten existieren somit mehrere Kundenstammdatensätze mit der gleichen Mail-Adresse im Shop.
Voraussetzung für die Nutzung
Um dieses Feature zu nutzen, muss der Shop speziell konfiguriert werden. Bitte kontaktieren Sie die WEBSALE AG, falls Mehrfachkonten erforderlich sein sollten.
Mehrfachkonten (CustomerID)
Normalerweise ist es über den Import nicht möglich mehrere Kundendatensätze mit der gleichen Kundennummer (CustomerID) anzulegen, da diese als Duplikate abgelehnt werden.
Bei Nutzung des Features „Mehrfachkonten (CustomerID)“ ist diese Beschränkung aufgehoben.
Im Vergleich zu dem Feature „Mehrfachkonten (eMail)“ ergibt sich die zusätzliche Komplikation, dass die Datensätze in den einzelnen Importdateien (z. B. custupdate.csv und billcomplete.csv) über UserIndex oder CustomerID verknüpft werden. Bei einer Neuanlage muss nun aber der UserIndex den Wert „0“ haben, so dass bei mehrdeutigen CustomerIDs keine eindeutige Zuordnung der Zeilen in den einzelnen Importdateien mehr möglich ist.
Aus diesem Grund muss bei Verwendung von „Mehrfachkonten (CustomerID)“ in jeder Importdatei das Feld „Email“ angegeben werden.
Eine Kombination von „Mehrfachkonten (CustomerID)“ mit „Mehrfachkonten (eMail)“ ist aus dem gleichen Grund nicht möglich.
Voraussetzung für die Nutzung
Um dieses Feature zu nutzen, muss der Shop speziell konfiguriert werden. Bitte kontaktieren Sie die WEBSALE AG, falls Mehrfachkonten erforderlich sein sollten.
Mail-Adressierung
Normalerweise wird ein Importdatensatz mit leerem Userindex (oder Userindex = 0) als Dublette abgelehnt, wenn die dort angegebene Mail-Adresse bereits für einen Kundendatensatz im Shop verwendet wird.
Bei aktivierter “Mail-Adressierung” wird in diesem Fall stattdessen der Datensatz mit der angegebenen Mail-Adresse überschrieben.
Das gleiche wird gemacht, wenn der in den Importdaten angegebene Userindex nicht in der Shopdatenbank existiert, d. h. es wird nach einem Datensatz mit übereinstimmender Mail gesucht und dieser wird überschrieben.
Vorteile
Es wird eine gewisse “Fehlertoleranz” erreicht. Wenn im ERP-System ein Kunde angelegt wird, der sich bereits selbst im Shop registriert hat, dann schlägt der Import normalerweise fehl, denn der Importdatensatz ist als “Neuanlage” gekennzeichnet und die Mail ist schon vergeben.
Zu diesem Fall kann es kommen, wenn das ERP den im Shop angelegten Kunden (noch) nicht eingelesen hat. Das kann passieren, wenn die Anlage im Shop und im ERP quasi gleichzeitig erfolgt ist oder wenn das ERP das Einlesen des Kundendatensatzes explizit abgelehnt hat (z. B. wegen einer unvollständigen Adresse).
Weiterhin kann auch dann noch ein Import eines Kundendatensatzes erfolgen, wenn in der ERP-Datenbank ein falscher Userindex steht, z. B. weil sich der Kunde im Shop gelöscht und wieder neu registriert hat und dieser Vorgang nicht im ERP angekommen ist.
Nachteile
Die “Fehlertoleranz” ist auch gleichzeitig ein Nachteil, weil sie Abweichungen zwischen ERP-Datenbank und Shop-Datenbank verschleiert.
So kann ein Sachbearbeiter durch die Neuanlage eines Kunden im ERP einen bereits vorhandenen Kundendatensatz im Shop überschreiben, ohne dass er in irgendeiner Form darauf hingewiesen wird.
Etwas ähnliches kann passieren, wenn der Userindex im ERP nicht mehr stimmt, auch dadurch können unbewusst Daten eines Shopkunden überschrieben werden, für den die Änderungen nicht gedacht waren.
Weiterhin können “Mehrfachkonten (eMail)” natürlich nicht in Kombination mit der “E-Mail-Adressierung“ verwendet werden.
Voraussetzung für die Nutzung
Um dieses Feature zu nutzen, muss der Shop speziell konfiguriert werden. Bitte kontaktieren Sie die WEBSALE AG, falls E-Mail-Adressierung erforderlich sein sollten.
Import-Dateien
Beschränkung der Feldlängen
Die Voreinstellung und gleichzeitig maximal zulässige Länge aller Kundendatenfelder ist 256 Zeichen.
Im Abschnitt “AddressMaxInputLen” der Shopkonfiguration „shop.config“ kann bei Bedarf die maximale Länge der einzelnen Felder, für die der Kunde im Shop Inhalte eingeben kann, herabgesetzt werden. Von dieser Möglichkeit sollten Sie Gebrauch machen, wenn die jeweilige Feldlänge in Ihrem System kleiner als 256 Zeichen ist.
Beschränkung der Dateigröße
Import per SFTP: 4 GB je Datei
Import per WSPManager: 1 GB je Datei
Übersicht über die Importdateien
Dateiname | Kommentar |
|---|---|
custupdate.csv | Zu aktualisierende und einzufügende Datensätze/ Zugangsdaten und Kundenoptionen |
custdelete.csv | Zu löschende Datensätze |
billupdate.csv | Zu aktualisierende und einzufügende Rechnungsadressen. |
billcomplete.csv | Zu aktualisierende und einzufügende Rechnungsadressen. Im Gegensatz zur Datei „billupdate.csv“ müssen in dieser Datei alle Rechnungsadressen eines Kunden enthalten sein. Nicht enthaltene Rechnungsadressen werden gelöscht. |
billdelete.csv | Zu löschende Rechnungsadressen. Diese Datei ist dafür gedacht, einzelne Adressen von bestimmten Kunden zu löschen. Beim Löschen des kompletten Kunden mit Hilfe der Datei “custdelete.csv” werden automatisch auch alle Rechnungsadressen gelöscht. |
delivupdate.csv | Zu aktualisierende und einzufügende Lieferadressen |
delivcomplete.csv | Zu aktualisierende und einzufügende Lieferadressen. (analog zu billcomplete.csv). |
delivdelete.csv | Zu löschende Lieferadressen (analog zu billdelete.csv). |
bankupdate.csv | Zu aktualisierende und einzufügende Bankverbindungen |
bankcomplete.csv | Zu aktualisierende und einzufügende Bankverbindungen (analog zu billcomplete.csv). |
bankdelete.csv | Zu löschende Bankverbindungen (analog zu billdelete.csv). |
Reihenfolge des Imports
Die Dateien werden in folgender Reihenfolge importiert:
*delete Dateien
custupdate.csv
Alle anderen *update Dateien
*complete Dateien
Es könnten also innerhalb eines Imports zuerst Datensätze eines Kunden gelöscht und danach wieder eingefügt werden, falls das aus Sicht des exportierenden Systems sinnvoll ist.
Aufgrund der Verarbeitung als letztes hat ein Komplett-Import aller Datensätze stets "die Oberhand". Werden mit einer update-Datei und in der zugehörigen complete-Datei also Datensätze für den gleichen Kunden übergeben, so überschreiben die Daten der complete-Datei die vorher importierten Daten der update-Datei.
Aufbau und Inhalt der Datei custupdate.csv
Über diese Datei können neue Datensätze im Shop angelegt und diverse Optionen für die Kunden gesetzt werden. Damit für einen Kunden Rechnungsadressen, Lieferadressen usw. importiert werden können muss immer auch zunächst ein Datensatz mit Hilfe der custupdate.csv angelegt werden.
Werden Pflichtfelder in der Datei nicht geliefert (d. h. fehlt die Spalte komplett), so bleiben die ursprünglich für diese Felder im Kundendatensatz gespeicherten Werte erhalten.
Die Datei enthält folgende Felder:
Feldname | Feldinhalt | Pflichtfeld ja/nein |
|---|---|---|
UserIndex | Der Tabellen-Schlüssel in der Shop-Datenbank (siehe Abschnitt Adressierung der Datensätze) | ja beim Ändern eines Datensatzes, verboten bei der Neuanlage eines Datensatzes (siehe Adressierung der Datensätze) |
CustomerID | Die Kundennummer | ja bei der Neuanlage eines Datensatzes, sonst: siehe Adressierung der Datensätze |
Password | Das Passwort mit dem sich der Kunde im Shop einloggen kann. | nein |
Die Mail-Adresse des Kunden | ja | |
MainSubshop | Ist hier eine Subshop-ID eingetragen, so kann sich der Kunde nur in diesen Subshop (und in die eventuell im Feld Subshop angegebenen Subshops) einloggen. Versucht sich ein Kunde in einen Subshop einzuloggen, für den er keine Zugangsberechtigung hat, so wird er in den unter “MainSubshop” angegebenen Subshop umgeleitet. Ist dieses Feld leer, so kann sich der Kunde in alle Subshops einloggen. | ja, wenn das Feld “Subshop” verwendet wird |
Subshop | Ist im Feld “MainSubshop” ein Subshop eingetragen, so kann im Feld “Subshop” eine kommagetrennte Liste von weiteren Subshops angegeben werden, in die sich der Kunde einloggen kann. Alternativ zu einer Liste von Subshops kann hier auch der Wert “*” eingetragen werden, in diesem Fall kann sich der Kunde in alle Subshops einloggen. | nein |
CharsetImport | Wenn die Kundendaten nicht in dem Zeichensatz geliefert werden können der im Shop verwendet wird, so kann der Zeichensatz mit diesen beiden Feldern konvertiert werden | nein |
CharsetShop | nein | |
AddressSharingLastChangeDate | Einwilligung zur Weitergabe von Adressen zu Werbezwecken: Datum der letzten Änderung des Zustandes im Format TT.MM.JJJJ | nein |
AddressSharingLastChangeIP | Einwilligung zur Weitergabe von Adressen zu Werbezwecken: IP-Adresse bei der letzten Änderung | nein |
AddressSharingLastChangeTime | Einwilligung zur Weitergabe von Adressen zu Werbezwecken: Zeit der letzten Änderung des Zustandes im Format SS:MM:SS (Stunden/Minuten/Sekunden) | nein |
AddressSharingState | Einwilligung zur Weitergabe von Adressen zu Werbezwecken: Status, mögliche Werte sind: | nein |
AgeResMail | Eine Mail-Adresse, an die das „AgeResPasswd“ geschickt werden kann | nein |
AgeRestricted | Das Alter des Kunden. Ist dieses Feld mit einem Wert größer 0 gefüllt, so werden dem eingeloggten Kunden nur Produkte angezeigt, deren „Altersbeschränkung“ kleiner oder gleich dem Alter des Kunden ist | nein |
AgeResPasswd | Das Passwort (für den Erziehungsberechtigten), mit dem das „AgeRestricted“ Feld geänderten werden kann | nein |
BillieDuration | Zeit in Tagen innerhalb derer der Kunde die Rechnung bezahlen muss (nur bei Zahlungsart Billie) Gültige Werte: 7 - 120 (überschreibt den Standardwert von 30 Tagen aus der Shopkonfiguration) | nein |
CreditCheckDate | Datum, zu dem eine (automatische, erneute) Bonitätsprüfung erfolgen soll. Format: YYYY-MM-DD Beispiel: 2022-03-17 | nein |
CreditPassState | 0/leer: nicht geprüft 1: positiv geprüft 2: negativ geprüft | nein |
Currency | Die Währung in der dem Kunden die Preise nach dem Login standardmäßig angezeigt werden. | nein |
CustomerDiscountOnly | „X“: Dem Kunden wird nur der unter “Discount” angegebene Kundenrabatt gewährt, keine anderen Rabatte. | nein |
DelCostDiscRate | Rabatt in %, den der Kunde auf die Versandkosten erhält. | nein |
DeliveryCostReduction | „X“: Für den Kunden gelten reduzierte Versandkosten | nein |
DeliveryDays | Kommaseparierte Liste der Wochentage an denen der Kunde beliefert werden kann. 1=Montag | nein |
DeliveryGroup | Versandkostengruppe, ermöglicht es artikelabhängige Versandkosten zusätzlich kundenabhängig zu machen. | nein |
Discount | Rabatt in %, den der Kunde beim Kauf von rabattierfähigen Artikeln erhält | nein |
DiscountGroupID | Suffix für Discount.dat, ermöglicht kundenabhängige Rabattgruppen. Beispiel: Wenn DiscountGroupID=“abc“, dann wird die Datei „discount_abc.dat“ vom Shop geladen. Wenn DiscountGroupID=““, dann wird die Standard-Datei „discount.dat“ vom Shop geladen. Das Format der „discount_*.dat“ Dateien ist in der Dokumentation WS-SFTP-Produkte PRO beschrieben. | nein |
DiscountList | Definition der möglichen Gruppierung an rabattierbaren Produkten für diesen Kunden. Wird dieses Feld verwendet, ignoriert der Shop den allgemeinen Rabattsatz. In diesem Feld können Rabatte für Produkte oder Kategorien geliefert werden, die der angegebenen Suchmaske entsprechen. Aufbau des Feldes: <g>(Type):(Rabattsatz)[:(Suchmaske)][:(abMenge-bisMenge)]</g>… Type kann die folgenden Werte haben: „Wildcard-Zeichen“ sind: Beispiele: Angaben mit und ohne Mengen können auch kombiniert werden. Dabei wird die erste Regel, die von links betrachtet zutrifft, verwendet. Beispiel: In der Kategorie “flyer” wird bis 1000 Stück 3% Rabatt gewährt, 2% bis 10.000 und 1% ab 10.000: <g>3:3.00:flyer:-999</g><g>3:2.00:flyer:1000-9999</g><g>3:1.00:flyer:10000-</g> | nein |
FreeDelivery | “X”: Der Kunde bezahlt keine Versandkosten | nein |
FreePayCost | “X”: Der Kunde bezahlt keine Zahlungsartenkosten | nein |
FreightCostsValue | Betrag eines Frachtkostenauf-/abschlages, z. B. 23.50 | nein |
FreightCostsType | Typ des Frachtkostenauf-/abschlages, mögliche Werte: A+=Absoluter Aufschlag | nein |
GroupLogin | „X“: Die Login-Daten werden von mehreren Usern verwendet („Gruppen-Login“). In diesem Fall können weder die Login-Daten noch die Adressdaten durch den eingeloggten User im Shop geändert werden. | nein |
InfoScoreState | 0/leer: nicht geprüft 1: positiv geprüft 2: negativ geprüft | nein |
LastOrderDate | Datum der letzten Bestellung im Format YYYY-MM-DD Dieses Feld ist für Bestellungen gedacht, die am Online-Shop vorbei gemacht wurden, z.B. telefonisch. Es kann dann zur Neukundenerkennung und zur Steuerung der Logiken beim Holen von Adressdatenänderungen verwendet werden. | nein |
MaxOrderForUserAccount | Steht in diesem Feld ein Wert > 0, so wird dieser statt des bei den Zahlungsarten in der shop.config eingetragenen “MaxOrder-Value” verwendet. | nein |
OrderGenerator | „X“: Falls dem eingeloggten Kunden ein Link zum „Bestellgenerator“ angeboten werden soll. | nein |
PayCostDiscRate | Rabatt in %, den der Kunde auf die Zahlungsartenkosten erhält |
|
PaymentMethods | Eine kommagetrennte Liste von Zahlungsarten-Codes der Zahlungsmethoden, die dem Kunden zur Verfügung stehen. Beispiele für Zahlungsarten-Codes: | nein |
ProductDiscount | “X”: Der Kundenrabatt wird beim Produkt angezeigt | nein |
PriceGroup | Eine Preisgruppe, sind für diese Preisgruppe beim Artikel-Import abweichende Preise angegeben worden, so werden dem Kunde diese statt der Default-Preise angezeigt. Auch wenn die Zuordnung von kundenabhängigen Preisen über die Kundennummer erfolgt muss dieses Feld einen nicht leeren Eintrag enthalten. Dieser „Dummy-Eintrag“ muss keiner existierenden Preisgruppe entsprechen und dient nur als Flag, damit der Online-Shop die Funktion „kundenabhängige Preise“ aktiviert. | nein |
RegistrationCode | "Freischaltcode", der Shop kann so eingerichtet werden, dass sich nur Kunden registrieren können, die einen Freischaltcode kennen. Dieser Freischaltcode wird vom Shop bei den Kundendaten gespeichert, ein Verändern des Wertes über den Import ist deshalb nicht sinnvoll wohl aber ein Löschen des Codes. | nein |
Releaser | „X“: Der Kunde kann die Bestellungen anderer Kunden freigeben | nein |
ReleaseID | Eine ID für das Freigabeverfahren | nein |
ReleaseRequired | „X“: Die Bestellungen des Kunden müssen freigegeben werden bevor sie ausgeführt werden. | nein |
Reseller | „X“: Der Kunden kann einen „Reseller-Aufschlag“ (Provision) eingeben, welcher dann zur Gesamtsumme der Bestellung hinzuaddiert wird | nein |
StartPage | Eine „Startseite“ die nach dem Login des Kunden angezeigt wird | nein |
SuperUserID | ID eines „Super-Users“ mit besonderen Rechten. Dieser kann sich z. B. als ein anderer User einloggen und für diesen bestellen. Jeder Kunde mit einer gefüllten SuperUserID gilt als „SuperUser“, die hier eingetragene ID wird in den Bestelldaten zurückgegeben. Es empfiehlt sich also für jeden SuperUser eine andere ID zu verwenden, damit in den Bestelldaten ersichtlich ist, wer die Bestellung ausgeführt hat. | nein |
SuperUserRestricted | „X“: Der „SuperUser“ darf nur auf die Kundendatensätze zugreifen, bei denen seine SuperUserID im Feld SuperUserIDList eingetragen ist. | nein |
SuperUserIDList | Eine kommagetrennte Liste der SuperUserIDs der SuperUser, die auf diesen Kundensatz zugreifen dürfen. | nein |
Surcharge | Zusätzlich zum globalen Mindermengenzuschlag ist es möglich, pro Kunde einen Betrag (SurchargeLimit) zu hinterlegen, bis zu welchem bei einer Bestellung ein Mindermengenzuschlag (Surcharge) pro Bestellung berechnet wird (Mindermengenzuschlags-Basis), wenn dieser unterschritten wird. Weiterhin kann pro Kunde die Höhe des Mindermengenzuschlags individuell hinterlegt werden. | nein |
SurchargeLimit | nein | |
TeleMarketingLastChangeDate | Einwilligung für Telefonwerbung: Datum der letzten Änderung des Zustandes im Format TT.MM.JJJJ | nein |
TeleMarketingLastChangeIP | Einwilligung für Telefonwerbung: IP-Adresse bei der letzten Änderung | nein |
TeleMarketingLastChangeTime | Einwilligung für Telefonwerbung: Zeit der letzten Änderung des Zustandes im Format SS:MM:SS | nein |
TeleMarketingState | Einwilligung für Telefonwerbung: Status, mögliche Werte sind: | nein |
UnitFactorGroupID | Wenn kundenabhängige Stückelungen verwendet werden sollen, so muss hier die Gruppen-ID eingetragen werden, die dann auch im Feld “UnitFactorGroups” in den Produktdaten benutzt wird. | nein |
Warranty | Kommagetrennte Liste der Berechtigungscodes des Kunden. Ein Berechtigungscode ist ein alphanumerischer String, dessen Inhalt festlegt, ob dem Kunden bestimmte Bereiche im Shop angezeigt werden oder nicht. Beispiel-Liste: 1,2,abc Der Kunde gehört den Berechtigungsgruppen „1“, „2“ und „abc“ an. Beispiel-Klammerungen in einem Template: {ST-Warranty(1,abc)}
Dieser Bereich wird dem
Kunden nur dann
angezeigt, wenn er der
Gruppe „1“ oder der
Gruppe „abc“ angehört.
{/ST-Warranty(1,abc)}
{!ST-Warranty(1,abc)}
Dieser Bereich wird
dem Kunden angezeigt,
wenn er weder der
Gruppe „1“ noch der
Gruppe „abc“ angehört.
{/!ST-Warranty(1,abc)} | nein |
WebsaleIni | Veraltet/deprecated: Der Name einer alternativen shop.config, die für den Kunden verwendet werden soll. | nein |
Aufbau und Inhalt der Datei custdelete.csv
Über diese Datei können Datensätze aus dem Shop gelöscht werden. Wird ein Datensatz mit der custdelete.csv gelöscht, so werden alle Daten des Kunden gelöscht, d. h. seine Rechnungsadressen, Lieferadressen usw.
Die Datei enthält folgende Felder:
Feldname | Feldinhalt | Pflichtfeld ja/nein |
|---|---|---|
UserIndex | Der Tabellen-Schlüssel in der Shop-Datenbank (siehe Abschnitt “Adressierung der Datensätze”) | Ja, wenn das Feld CustomerID fehlt oder leer ist (siehe Adressierung der Datensätze) |
CustomerID | Die Kundennummer | Ja, wenn das Feld UserIndex fehlt, leer oder 0 ist (siehe Adressierung der Datensätze) Wenn das Feld UserIndex fehlt, leer oder 0 ist und eine Kundennummer angegeben ist, dann werden alle Datensätze gelöscht, die zu dieser Kundennummer passen. |
Aufbau und Inhalt der Datei billupdate.csv/billcomplete.csv
Diese Dateien enthalten die einzufügenden oder zu aktualisierenden Rechnungsadressen. Der Aufbau der beiden Dateien ist identisch. Die enthaltenen Daten werden jedoch beim Import unterschiedlich behandelt:
Datensätze eines Kunden die in der billupdate.csv nicht enthalten sind bleiben in der Kundendatenbank des Shops erhalten, während sie beim Import der identischen Daten in einer billcomplete.csv gelöscht werden.
Beispiel
Die Kundendatenbank des Shops enthält zwei Kunden mit den Kundennummern “123” und “ABC”. Für den Kunde “123” sind in der Kundendatenbank 5 Rechnungsadressen gespeichert. In der billupdate.csv/billcomplete.csv sind für den gleichen Kunden 3 Rechnungsadressen vorhanden. Der Kunde “ABC” taucht in den Importdateien nicht auf.
Beim Import der Daten als “billcomplete.csv” würden die 5 Rechnungsadressen des Kunden “123” aus der Datenbank durch die 3 Rechnungsadressen aus der Importdatei ersetzt.
Beim Import der Daten als “billupdate.csv” werden die 3 Adressen aus den Importdaten zu den bereits in der Kundendatenbank vorhandenen Adressen hinzugefügt bzw. die vorhandenen Adressen aktualisiert.
Die Daten des Kunden “ABC” bleiben in beiden Fällen unverändert in der Kundendatenbank erhalten.
Bitte beachten Sie, dass der Shop bisher nur eine Rechnungsadresse je Kunde unterstützt.
Die Dateien enthalten folgende Felder:
Feldname | Feldinhalt | Pflichtfeld ja/nein |
|---|---|---|
UserIndex | Der Tabellen-Schlüssel in der Shop-Datenbank (siehe Abschnitt Adressierung der Datensätze) | ja beim Ändern eines Datensatzes, verboten bei der Neuanlage eines Datensatzes (siehe Adressierung der Datensätze) |
CustomerID | Die Kundennummer | ja bei der Neuanlage eines Datensatzes, sonst: siehe Adressierung der Datensätze |
TableIndex | Der Tabellen-Schlüssel in der Shop-Datenbank | Dieses Feld ist derzeit optional, da der Shop nur eine Rechnungsadresse je Kunde unterstützt |
ExternalID | Die ID des Datensatzes für den Kunden. | ExternalID: ja bei der Neuanlage eines Datensatzes. Optional beim Update einer Rechnungsadresse. (siehe Adressierung der Datensätze |
BCCEMail | Kommagetrennte Liste von Mail-Adressen an die die Bestellbestätigungen als "blind carbon copy" geschickt werden sollen. | nein |
BusinessFax | Fax (geschäftlich) | nein |
BusinessPhone | Telefon (geschäftlich) | nein |
CCEMail | Kommagetrennte Liste von Mail-Adressen an die die Bestellbestätigungen als "carbon copy" geschickt werden sollen. | nein |
City | Wohnort | nein |
Company | Firma | nein |
CompleteSalutation | Komplette Anrede, z. B. „Sehr geehrter Herr Müller“. Dieses Feld kann verwendet werden, wenn beim Import der Daten eine Begrüßungs-Mail an Neukunden verschickt werden soll. Für den Shop ist es ohne Bedeutung. | nein |
CostCenter | Kostenstelle | nein |
CountryISO | Dreistelliger ISO-Code des Landes | nein |
DateOfBirth | Geburtsdatum im Format TT.MM.JJJJ | nein |
Department | Abteilung | nein |
EMail2 | Mail-Adresse für Rechnung | nein |
Fax | Fax | nein |
FirstName | Vorname | nein |
LastName | Nachname | nein |
MobilePhone | Mobiltelefon | nein |
Phone | Telefon | nein |
PostOfficeBox | Postfach | nein |
PostOfficeBoxZip | Postleitzahl des Postfachs | nein |
Salutation | Anrede, z. B. „Herr“. Dieses Feld wird vom Shop nur verwendet, wenn der "SalutationCode" nicht gefüllt ist. Es wird empfohlen statt "Salutation" das Feld "SalutationCode" zu importieren und den Text der Anrede (z. B. „Herr“) in der Konfiguration „salutation.dat“ einzutragen. | nein |
SalutationCode | Code der Anrede, z. B. „11“. Die Codes und die zugehörigen Einstellungen werden in der Konfiguration „salutation.dat“ konfiguriert. Der Zugriff erfolgt über den Dienst "Konfiguration" im Online-Servicebereich. | nein |
State | Land, z. B. „Bayern“ | nein |
Street1 | Straße / Hausnummer | nein |
Street2 | 2. Straße / Hausnummer | nein |
Suffix1-50 | Frei verwendbare Adressdatenfelder | nein |
TaxId | Umsatz-ID | nein |
TaxIds | Umsatz-IDs für Reihengeschäfte, Beispiel: <g>DEU:ok:DE123456789</g><g>BEL:unchecked:BE0999999999</g><g>AUT:failed:AT0999999999</g> | nein |
Title | Titel, z. B. „Dr.“ | nein |
TitleCode | Code des Titels, z. B. „11“. Die Codes und die zugehörigen Einstellungen werden in der Konfiguration „title.dat“ konfiguriert. Der Zugriff erfolgt über den Dienst "Konfiguration" der SubShops im Online-Servicebereich. | nein |
UserDescr | Ein Kommentar, der im Shop bei der Adressauswahl angezeigt wird | nein |
UserType | „Typ“ des Kunden, muss einem in der shop.config konfigurierten Wert entsprechen | nein |
Zip | Postleitzahl | nein |
Aufbau und Inhalt der Datei billdelete.csv
Über diese Datei können einzelne Rechnungsadressen aus dem Shop gelöscht werden. Sollen alle Daten eines Kunden gelöscht werden, so genügt es den Datensatz mit der custdelete.csv zu löschen, ein Löschen der einzelnen Rechnungsadressen mit der billdelete.csv ist in diesem Fall nicht nötig.
Die Datei enthält folgende Felder:
Feldname | Feldinhalt | Pflichtfeld ja/nein |
UserIndex | Der Tabellen-Schlüssel in der Shop-Datenbank (siehe Abschnitt “Adressierung der Datensätze”) | Ja, wenn das Feld CustomerID fehlt oder leer ist |
CustomerID | Die Kundennummer | Ja, wenn das Feld UserIndex fehlt, leer oder 0 ist |
TableIndex | Der Tabellen-Schlüssel in der Shop-Datenbank | Ja, wenn das Feld ExternalID fehlt oder leer ist |
ExternalID | Die ID des Datensatzes für den Kunden. | Ja, wenn das Feld TableIndex fehlt, leer oder 0 ist |
Aufbau und Inhalt der Datei delivupdate.csv/delivcomplete.csv
Diese Dateien enthalten die einzufügenden oder zu aktualisierenden Lieferadressen. Diese werden analog zu den Dateien billupdate.csv bzw. billcomplete.csv behandelt. Lieferadressen müssen für einen Kunden nur dann importiert werden, wenn sie von den Rechnungsadressen abweichen.
Die Dateien enthalten folgende Felder:
Feldname | Feldinhalt | Pflichtfeld ja/nein |
|---|---|---|
UserIndex | Der Tabellen-Schlüssel in der Shop-Datenbank (siehe Abschnitt “Adressierung der Datensätze”) | ja beim Ändern eines Datensatzes, verboten bei der Neuanlage eines Datensatzes (siehe Adressierung der Datensätze) |
CustomerID | Die Kundennummer | ja bei der Neuanlage eines Datensatzes, sonst: siehe Adressierung der Datensätze |
TableIndex | Der Tabellen-Schlüssel in der Shop-Datenbank | TableIndex: ja beim Ändern eines Datensatzes, verboten bei der Neuanlage eines Datensatzes (siehe Adressierung der Datensätze) |
ExternalID | Die ID des Datensatzes für den Kunden. | ExternalID: ja bei der Neuanlage eines Datensatzes, sonst optional (siehe Adressierung der Datensätze |
City | Wohnort | nein |
Company | Firma | nein |
CostCenter | Kostenstelle | nein |
CountryISO | Dreistelliger ISO-Code des Landes | nein |
Department | Abteilung | nein |
Mail für Lieferadresse | nein | |
FirstName | Vorname | nein |
LastName | Nachname | nein |
Phone | Telefon | nein |
PostOfficeBox | Postfach | nein |
PostOfficeBoxZip | Postleitzahl des Postfachs | nein |
Salutation | Anrede, z. B. „Herr“. Dieses Feld wird vom Shop nur verwendet, wenn der "SalutationCode" nicht gefüllt ist. Es wird empfohlen statt "Salutation" das Feld "SalutationCode" zu importieren und den Text der Anrede (z. B. „Herr“) in der Konfiguration „salutation.dat“ einzutragen. | nein |
SalutationCode | Code der Anrede, z. B. „11“. Die Codes und die zugehörigen Einstellungen werden in der Konfiguration „salutation.dat“ konfiguriert. Der Zugriff erfolgt über den Dienst "Konfiguration" im Online-Servicebereich. | nein |
State | Land, z. B. „Bayern“ | nein |
Street1 | Straße / Hausnummer | nein |
Street2 | 2. Straße / Hausnummer | nein |
Suffix1-50 | Frei verwendbare Adressdatenfelder | nein |
Title | Titel, z. B. „Dr.“ | nein |
TitleCode | Code des Titels, z. B. „11“ (die Codes und die zugehörigen Einstellungen werden in der Datei „title.dat“ über den Dienst „Konfiguration“ der SubShops konfiguriert) | nein |
UserDescr | Ein Kommentar, der im Shop bei der Adressauswahl angezeigt wird | nein |
Zip | Postleitzahl | nein |
Aufbau und Inhalt der Datei delivdelete.csv
Über diese Datei können einzelne Lieferadressen aus dem Shop gelöscht werden, sie wird analog zu der Datei billdelete.csv behandelt.
Die Datei enthält folgende Felder:
Feldname | Feldinhalt | Pflichtfeld ja/nein |
|---|---|---|
UserIndex | Der Tabellen-Schlüssel in der Shop-Datenbank (siehe Abschnitt “Adressierung der Datensätze”) | Ja, wenn das Feld CustomerID fehlt oder leer ist |
CustomerID | Die Kundennummer | Ja, wenn das Feld UserIndex fehlt, leer oder 0 ist |
TableIndex | Der Tabellen-Schlüssel in der Shop-Datenbank | Ja, wenn das Feld ExternalID fehlt oder leer ist |
ExternalID | Die ID des Datensatzes für den Kunden. | Ja, wenn das Feld TableIndex fehlt, leer oder 0 ist |
Aufbau und Inhalt der Datei bankupdate.csv/bankcomplete.csv
Diese Dateien enthalten die einzufügenden oder zu aktualisierenden Daten der Bankverbindung, sie werden analog zu den Dateien billupdate.csv bzw. billcomplete.csv behandelt.
Die Dateien enthalten folgende Felder:
Feldname | Feldinhalt | Pflichtfeld ja/nein |
|---|---|---|
UserIndex | Der Tabellen-Schlüssel in der Shop-Datenbank (siehe Abschnitt “Adressierung der Datensätze”) | ja beim Ändern eines Datensatzes, verboten bei der Neuanlage eines Datensatzes (siehe Adressierung der Datensätze) |
CustomerID | Die Kundennummer | ja bei der Neuanlage eines Datensatzes, sonst: siehe Adressierung der Datensätze |
TableIndex | Der Tabellen-Schlüssel in der Shop-Datenbank | TableIndex: ja beim Ändern eines Datensatzes, verboten bei der Neuanlage eines Datensatzes (siehe Adressierung der Datensätze) |
ExternalID | Die ID des Datensatzes für den Kunden. | ExternalID: ja bei der Neuanlage eines Datensatzes, sonst optional (siehe Adressierung der Datensätze |
AccountNumber | Kontonummer | nein |
Bank | Name der Bank | nein |
BankCode | Die Bankleitzahl | nein |
BIC | Bank Identifier Code | nein |
CountryISO | Dreistelliger ISO-Code des Landes | nein |
IBAN | International Bank Account Number | nein |
Owner | Inhaber des Kontos | nein |
SEPALastMandate | Letzte SEPA-Mandatsnummer | nein |
SEPAMandateType | Sepa-Mandats-Typ 0: nicht gesetzt | nein |
SEPADebitType | SEPA-Lastschrift-Art 0: nicht gesetzt | nein |
SEPAMandateDate | Datum der Mandats-Einwilligung | nein |
UserDescr | Ein Kommentar, der im Shop bei der Auswahl der Bankverbindung angezeigt wird | nein |
Aufbau und Inhalt der Datei bankdelete.csv
Über diese Datei können einzelne Bankverbindungen aus dem Shop gelöscht werden, sie wird analog zu der Datei billdelete.csv behandelt.
Die Datei enthält folgende Felder:
Feldname | Feldinhalt | Pflichtfeld ja/nein |
|---|---|---|
UserIndex | Der Tabellen-Schlüssel in der Shop-Datenbank (siehe Abschnitt “Adressierung der Datensätze”) | Ja, wenn das Feld CustomerID fehlt oder leer ist |
CustomerID | Die Kundennummer | Ja, wenn das Feld UserIndex fehlt, leer oder 0 ist |
TableIndex | Der Tabellen-Schlüssel in der Shop-Datenbank | Ja, wenn das Feld ExternalID fehlt oder leer ist |
ExternalID | Die ID des Datensatzes für den Kunden. | Ja, wenn das Feld TableIndex fehlt, leer oder 0 ist |
Zeichensatzkonvertierung
Wenn die Adressdaten nicht in dem Zeichensatz geliefert werden können, der vom Shop verwendet wird, so kann der Zeichensatz beim Import konvertiert werden. Dafür stehen zwei Möglichkeiten zur Verfügung:
1) Verwendung der Felder „CharsetImport“ und „CharsetShop“
Diese beiden Felder müssen in der Datei custupdate.csv für jeden importierten Datensatz angegeben werden und enthalten den Zeichensatz des Datensatzes in den Importdaten und den Zeichensatz der im Shop verwendet werden soll.
2) Konfiguration der Konvertierung in der Datei global.config
Hierbei wird in der Datei „global.config“ im Verzeichnis „konfiguration“ eingestellt in welchem Zeichensatz die Kundendaten geliefert werden. Die Datei „global.config“ ist im Shop optional und muss deshalb eventuell erst angelegt werden.
Der Zeichensatz des Shops wird aus der „shop.config“ gelesen. Damit der Subshop (und damit die zu verwendende shop.config) bestimmt werden kann, muss bei dieser Methode bei jedem Datensatz das Feld „MainSubhop“ gefüllt sein.
Beispiel für die Konfiguration in der global.config
<CustomerImportPro>
ConvertCharset = yes # [yes|no], standard = no
ImportCharset = UTF-8 # standard = UTF-8
UnknownCharacters = mapreplace # standard = ignore
</CustomerImportPro>
<+ImportCharsetConvertMap>
Charset = ISO-8859-1
a = %c4%83
$delete = %c3%8d
%56 = %c3%8e
s = %c5%9f
</+ImportCharsetConvertMap>Einziger Pflichtparameter ist „ConvertCharset“, denn nur wenn dieser Parameter den Wert „yes“ hat wird der Zeichensatz überhaupt konvertiert. „ImportCharset“ gibt den Zeichensatz der Importdatei an. Fehlt der Parameter oder ist er leer, so wird der Zeichensatz „UTF-8“ verwendet.
„UnknownCharacters“ regelt das Verhalten, wenn die Importdatei Zeichen enthält die im Zeichensatz des Shops nicht vorhanden sind. Der Default-Wert ist „ignore“. Dabei werden Zeichen, die sich nicht konvertieren lassen, komplett weggelassen. Bei „stdreplace“ wird versucht, unbekannte Zeichen durch ein oder mehrere ähnlich aussehende Zeichen zu ersetzen. Der Wert „mapreplace“ bewirkt, dass vor der eigentlichen Konvertierung konfigurierbare Ersetzungen vorgenommen werden. Wenn sich Zeichen auch nach diesen Ersetzungen nicht konvertieren lassen, so werden sie (wie bei „ignore“) weggelassen.
Welche Zeichen durch was ersetzt werden, wird in den „<+ImportCharsetConvertMap>“ Sektionen festgelegt.
In der Datei global.config kann es mehrere dieser Sektionen geben. Für jeden benötigten Zeichensatz eine. Der Parameter „Charset“ gibt den Zeichensatz an für den die Sektion verwendet werden soll, alle anderen Parameter stellen Ersetzungsregeln dar. Links vom „=“ steht dabei ein Zeichen oder eine Zeichenfolge aus der Importdatei, rechts davon die gewünschte Ersetzung. Da sich der Zeichensatz der Importdatei im allgemeinen vom Zeichensatz der global.config unterscheidet, können die Zeichen URL-kodiert angegeben werden. Bei dieser Kodierung wird ein Zeichen im wesentlichen durch seinen hexadezimalen Code ersetzt und dem Code ein „%“ vorangestellt.
Ausgenommen von der Zeichensatzkonvertierung sind die Felder „CustomerID“, „Mail“, „Subshop“ und „MainSubshop“.
Begrüßungsmails für Neukunden
Es besteht die Möglichkeit jedem Neukunden, dessen Daten über die Datei „custupdate.csv“ importiert wurden, eine „Begrüßungsmail“ zu senden. Ein Kunde in der „custupdate.csv“ gilt als Neukunde, wenn eine der beiden folgenden Bedingungen erfüllt ist:
Der Kunde stand vor dem Import noch nicht in der Datenbank
Der Kunde hatte vorher keine Kundennummer und ihm wird über die „custupdate.csv“ eine neue zugewiesen
Der Text der Mail, die an den Kunden gesendet wird, wird aus einem Template gebildet, das in der shop.config konfiguriert wird:
<NewCustomerMail>
...
Template = mail_newcustomer.htm
</NewCustomerMail>Die Template-Datei liegt in dem Verzeichnis ".../benutzter/templates/<subshop>/"
Das Template, das für den Versand der Begrüßungsmail verwendet wird, hängt also vom Inhalt des „MainSubshop“ Feldes in der Importdatei ab. Fehlt dieses Feld oder ist es leer, so kann keine Begrüßungsmail versendet werden.
Der Absendername, die Absenderadresse und der Betreff der Begrüßungsmail werden ebenfalls in der shop.config festgelegt:
Ist das Absenden einer Begrüßungsmail nicht erwünscht, so kann dies verhindert werden in dem der Parameter "Allow" auf "no" gesetzt wird:
Alternativ oder zusätzlich kann das Template gelöscht oder umbenannt werden.
Folgende Platzhalter stehen in dem Mail-Template zur Verfügung:
Platzhalter | Ersetzung |
|---|---|
~A-CompleteSalutation~ | Die vollständige Anrede, so wie sie im Feld “CompleteSalutation” importiert wurde |
~A-Salutation~ | Die Anrede, so wie sie im Feld “Salutation” importiert wurde |
~A-FirstName~ | Der Vorname des Kunden |
~A-LastName~ | Der Nachname des Kunden |
~A-UID~ | Die Login-ID des Kunden |
~A-Number~ | Die Kundennummer |
~A-E-Mail~ | Die Mail-Adresse |
Alle Adressdaten (A-CompleteSalutation, A-Salutation, A-FirstName, A-LastName) werden aus der ersten Rechnungsadresse des Kunden gelesen.
Zwangsänderung Passwort
Mit diesem Feature lässt sich erreichen, dass ein über den Import angelegter Kunde nach dem ersten Login sein Passwort ändern muss. Setzen Sie dazu in der shop.config den Parameter "NewUserPWChangeRequired" im Abschnitt "UserData" auf "yes".
Behandlung von gelöschten Zugängen
Kunden haben die Möglichkeit ihre Zugänge zum Shop zu löschen bzw. zu deaktivieren. Diese "gelöschten" Datensätze bleiben zunächst in der Datenbank und werden dort nur als gelöscht geflaggt.
Wenn sie versuchen für gelöschte Datensätze Daten zu importieren, so werden die Änderungen ignoriert. Ein Löschen der Daten über die custdelete.csv ist jedoch möglich bzw. sogar erforderlich um die Daten tatsächlich aus der Datenbank zu entfernen.
Hintergrund dieses Verhaltens ist, dass Warenwirtschaftssysteme Kundendaten normalerweise nicht löschen können. Würden die Kundendaten komplett aus der Shop-Datenbank gelöscht so bestünde die Gefahr, dass die Warenwirtschaft die im Shop gelöschten Daten wieder in den Shop importiert. Der Kunde, der seinen Zugang im Shop gelöscht hat würde sich dann zurecht wundern, warum sein gelöschter Zugang auf einmal wieder aktiv ist.
Beispieldateien
Teil dieser Dokumentation sind folgende Beispieldateien, die Sie auf der untergeordneten Seite zum Download finden:
Verzeichnis | Kommentar |
|---|---|
Complete | Mit diesen Importdateien werden die Kunden “Müller” und “Maier” neu in der Kundendatenbank angelegt. |
Update | In diesem Beispiel wird dem Kunden “Schulze” eine Kundennummer zugewiesen. Dieser Kunde hat sich über den Shop angemeldet und von diesem den UserIndex “123” bekommen. Weiterhin werden für die Adressen und die Bankverbindung “ExternalIDs” vergeben, mit denen diese in Zukunft in den Importdateien adressiert werden können. Beachten Sie, dass dies das einzige Beispiel ist in dem das Feld “TableIndex” verwendet wird. Da es der einzige Zweck dieser Dateien ist dem vom Shop angelegten Datensatz eine Kundennummer und “ExternalIDs” zuzuweisen, sind die restlichen Felder leer. |
Delta | In diesem Beispiel wird für den Kunden “Müller” eine Lieferadresse hinzugefügt, eine der Bankverbindungen gelöscht und die Rechnungsadresse geändert. Es wird davon ausgegangen, dass der Kunde bei der Anlage den UserIndex 123 erhalten hat. |
Delete | Diese Datei löscht den Kunden Müller mit allen Adressen und Bankverbindungen aus der Datenbank. |
Orderquantity | Beispiel für das Anlegen und Löschen von kundenabhängigen, minimalen und maximalen Bestellmengen |
Fehlercodes
Code | Kommentar |
|---|---|
EC001 | In der Importdatei ist weder das Headerfeld “UserIndex” noch das Headerfeld “CustomerID” vorhanden, der Import der Kundendaten wurde abgebrochen. |
EC002 | In der Importdatei ist weder das Headerfeld “TableIndex” noch das Headerfeld “ExternalID” vorhanden, der Import der Kundendaten wurde abgebrochen. |
EC003 | Für den Datensatz ist sowohl CustomerID als auch UserIndex leer, er wurde deshalb ignoriert. |
EC004 | Für den Datensatz ist sowohl ExternalID als auch TableIndex leer, er wurde deshalb ignoriert. |
EC005 | Weder die CustomerID noch der UserIndex des Datensatzes existiert in der Datenbank. |
EC006 | In der Importdatei wurde ein TableIndex angegeben, der für den zugehörigen Kundendatensatz nicht existiert, aber bei einem anderen Kunden bereits verwendet wird. Da der TableIndex tabellenweit eindeutig sein muss konnte der Datensatz nicht angelegt werden. Es wird empfohlen beim Anlegen von neuen Datensätzen den TableIndex leer zu lassen und Generierung der Datenbank zu überlassen. |
EC007 | Der Datensatz enthält keine Mail-Adresse. Da V8-Shops die Mail-Adresse zur Anmeldung benötigen wird der Datensatz deshalb ignoriert. |
EC008 | Der zu importierende Datensatz existiert in der Datenbank noch nicht, aber die angegebene Mail-Adresse wird bereits bei einem anderen Datensatz verwendet. Mehrere Datensätze mit der gleichen Mail-Adresse sind nur zulässig, wenn in mindestens einem Subshop Mehrfachkonten eingerichtet sind. |
EC009 | Unter Verwendung des UserIndex wurde versucht einem bereits in der Datenbank vorhandenen Kunden eine Kundennummer zugewiesen, die bereits für einen anderen Kunden verwendet wird. |
EC010 | CharsetImport ohne CharsetShop wird ignoriert. Wenn der Zeichensatz beim Import konvertiert werden soll, dann muss sowohl der Ausgangszeichensatz (CharsetImport) als auch der Zielzeichensatz (CharsetShop) angegeben werden. |
EC011 | CharsetShop ohne CharsetImport wird ignoriert. |
EC012 | ... Strings konnten nicht fehlerfrei in den Zielzeichensatz konvertiert werden. |
EC013 | Ungültiger Zeichensatz (... oder ...). Einer der angegebenen Zeichensätze wird vom Import nicht unterstützt. |
EC014 | Es sind sowohl verschlüsselte als auch mit SFTP übertragene Daten vorhanden. Diese Meldung ist nur relevant, wenn die Kundendaten über die Artikelimport Pro Schnittstelle importiert werden. Die Importdaten können entweder verschlüsselt in das Shopverzeichnis gespielt werden oder unverschlüsselt per SFTP in ein speziell dafür vorgesehenes Verzeichnis. |
EC015 | Das Feld 'UserIndex' ist in den Importdaten nicht vorhanden, obwohl es bei den konfigurierten Importoptionen ein Pflichtfeld ist. |
EC016 | UserIndex ... existiert nicht. |
EC017 | TableIndex ... durch ... ersetzt. Es wurde eine Rechnungsadresse mit einem TableIndex importiert, obwohl für den Kunden schon eine Rechnungsadresse mit einem anderen TableIndex vorhanden war. Statt des TableIndex aus der Importdatei wurde der vorhandene TableIndex verwendet. |
EC018 | Mehr als eine Rechnungsadresse vorhanden. |
EC019 | In der Datei ... fehlt das Pflichtfeld ... |
EC020 | Das Pflichtfeld ... ist leer (Datei: ... Zeile: ...) |
EC021 | Ungültiger Datentyp ... im Feld ... (Datei: ..., Zeile: ...) |
EC022 | UserIndex ist leer (Datei: ..., Zeile: ...) |
EC023 | Ungültiger Wert für 'TableIndex': … (Datei: …, Zeile: …) Der TableIndex ist keine Zahl oder überschreitet den maximalen Wert (2147483647) |
EC024 | Ungültige Indizes (<1 oder >…) für Produktkundengruppe in groupproductupdate.csv Beim Import der Produktkundengruppen wird nur die Summe der Zeilen mit ungültigen Indizes geloggt, nicht jede einzelne ungültige Zeile. Mit “Index” ist das Feld “GroupIdx” in der Import-Datei gemeint. Ungültig ist der Wert entweder, weil er die Zahl der freigeschalteten Gruppen überschreitet, weil er keine Zahl darstellt oder weil der Wert <1 ist. |
EC025 | Keine Kundendatenbank vorhanden. Dies ist ein interner Fehler der auftritt, wenn beim Anlegen des Shops durch WEBSALE keine Kundendatenbank angelegt wurde. |
EC026 | 'CustomerID' nicht in der Datenbank vorhanden (Datei: …, Zeile: …) In der angegebene Importdatei ist kein UserIndex angegeben und auch für die Kundennummer existiert kein passender Kundendatensatz in der Datenbank. |
EC027 | Maximale Zahl von Prime-Paketen (10) für den Kunden … überschritten |
EC028 | Ungültiges Format für ValidFrom oder ValidUntil (Datei: …, Zeile: …) |
EC029 | Mehrfachkonten und Mail-Adressierung können nicht gleichzeitig verwendet werden. Mehrfachkonten zeichnen sich gerade dadurch aus, dass mehrere Kundendatensätze die gleiche E-Mail-Adresse habe. Daher kann die E-Mail nicht zu Adressierung von Datensätzen verwendet werden, weil eventuell mehrere Datensätze dazu passen würden) |
EC030 | 'UserIndex' nicht in der Datenbank vorhanden (Datei: …, Zeile: ~linenum~) In einer Importdatei ist ein UserIndex > 0 angegeben, aber es existiert kein passender Kundendatensatz in in der Datenbank. Der Datensatz wird daher ignoriert. |
Fehler-Mails beim Import über den WSPManager
Bei Übertragung der Kundenimportdateien mit dem WSPManager wird die Liste der aufgetretenen Fehler und Warnungen gekürzt, wenn sie eine bestimmte Länge überschreitet.
Die vollständige Liste der aufgetretenen Fehler und Warnungen können Sie sich per Mail zuschicken lassen, konfigurieren Sie dazu die folgenden Sektionen in der shop.config des ersten Subshops:
Weitere Importdateien
Übersicht der „weiteren Importdateien“
Importdaten | Dateiname |
|---|---|
Produktkundengruppen (Zuordnung Kunden/Gruppe) | groupproductupdate.csv |
Kundenkonten, Bonuspunkte, Zuschüsse | accountupdate.csv |
Angebotsdaten | offerheadupd.dat/offerheadupd.csv |
Kundenabhängige Bestellmengen | orderquantityupdate.csv |
Prime-Pakete | primeupdate.csv |
Import von Produktkundengruppen
Mit Produktkundengruppen lassen sich Kategorien im Shop ein- oder ausblenden, je nachdem welcher Kunde sich im Shop eingeloggt hat.
Die Zuordnung von Kunden zu Produktkundengruppen erfolgt über zwei zusätzliche Dateien im „customerimport“ Verzeichnis: „groupproductupdate.csv“ und „groupproductdelete.csv“.
Mit der Datei „groupproductupdate.csv“ können Kunden Produktkundengruppen zugewiesen werden, mit der Datei „groupproductdelete.csv“ können diese Zuweisungen wieder gelöscht werden.
Aufbau der Datei „groupproductupdate.csv“
Feldname | Feldinhalt |
|---|---|
CustomerID | Kundennummer so wie sie dem Kunden in der Datei „custupdate.csv“ zugewiesen wurde |
GroupIdx | Der Index der Gruppe, z. B. „1“. Der niedrigste mögliche Wert für das Feld ist „1“, der maximale Wert hängt davon ab, wie viele Produktkundengruppen für den Shop freigeschaltet sind. Übersteigt der Wert die Anzahl der freigeschalteten Produktkundengruppen, so wird ein Fehler geloggt und die Zuweisung wird ignoriert. |
Um dem Kunden mit der Kundennummer „1234“ z. B. die Produktkundengruppen 1 und 2 zuzuweisen könnte man folgende Datei verwenden:
CustomerID<TAB>GroupIdx
1234<TAB>1
1234<TAB>2
(„<TAB>“ steht in diesem Beispiel für das Tabulator-Zeichen/den ASCII-Code 9. Wenn dem Kunden vor dem Import bereits andere Produktkundengruppen zugeordnet waren, so bleiben diese erhalten)
Aufbau der Datei „groupproductdelete.csv“
Feldname | Feldinhalt |
|---|---|
CustomerID | Kundennummer so wie sie dem Kunden in der Datei „custupdate.csv“ zugewiesen wurde oder „*“, falls eine Produktkundengruppe für alle Kunden gelöscht werden soll. |
GroupIdx | Der Index der Gruppe (z. B. „1“) oder „*“, falls alle Gruppen für einen Kunden gelöscht werden sollen. (Siehe auch die Feldbeschreibung in „groupproductupdate.csv“) |
Mit der folgenden Datei würde der Kunde mit der Kundennummer „1234“ aus der Produktkundengruppe „1“ entfernt, sowie die komplette Produktkundengruppe „2“ gelöscht:
CustomerID<TAB>GroupIDx
1234<TAB>1
*<TAB>2
Import von Daten für Kundenkonten, Bonuspunkte, Zuschüsse
Kundenkonten, Bonuspunkte und Zuschüsse sind vorgesehen für die Realisierung von Bonus-Systemen und Guthaben, die im Shop eingelöst werden können.
Bonuspunkte:
Ein Kunde bekommt z. B. für den Kauf eines Produkts eine Anzahl Bonuspunkte gutgeschrieben. Hat er genug Bonuspunkte zusammen, so kann er diese im Shop einlösen.
Wenn Sie keine Bonuspunkte anbieten, dann können Sie die Spalte "BonusPoints" in der Importdatei weglassen.
Kundenkonto:
Hier können Sie Kunden beliebige Guthaben gutschreiben. Beim Kauf wählt der Kunde dann die Zahlungsart "Kundenkonto" aus und bezahlt mit seinem Guthaben. WEBSALE reduziert automatisch das Guthaben nach einem Kauf.
Wenn Sie kein Kundenkonto anbieten, dann können Sie die Spalte "Credit" in der Importdatei weglassen.
Zuschuss:
Hier können Sie Kunden beliebige Zuschüsse gutschreiben. Der gewährte Zuschuss wird im Warenkorb von der Gesamtsumme abgezogen. Bei Bestellaufgabe wird der gewährte Zuschuss vom Zuschuss-Konto automatisch vom Shop abgezogen. Ein evtl. Restbetrag wird bei Folgebestellungen berücksichtigt, solange bis der Zuschuss aufgebraucht wurde.
Das Einlesen der Kundenkonto-Daten erfolgt über eine zusätzliche Datei mit Namen „accountupdate.csv“ im „customerimport“ Verzeichnis.
Aufbau der Datei „accountupdate.csv“
Feldname | Feldinhalt |
|---|---|
UserIndex | UserIndex |
BonusPoints | Zahl Bonuspunkte des Kunden (ganzzahlig) |
Credit | Guthaben des Kundenkontos |
Subvention | Zuschuss |
Bemerkungen:
Für die Adressierung der Datensätze wird der UserIndex verwendet, das bedeutet somit indirekt, dass Kundenkontodaten nur für Kunden importiert werden können, die bereits in der Datenbank existieren, denn ansonsten ist der UserIndex nicht bekannt.
Bei den Bonuspunkten, Guthaben und Zuschüssen, können neben absoluten Werten auch Differenzen angegeben werden. Zu diesem Zweck wird dem Wert ein „+“ oder ein „-“ vorangestellt.
Hat ein Kunde z. B. 100 Bonuspunkte auf seinem Konto und Sie importieren den Wert „10“ in der Spalte „BonusPoints“ so wird der Wert in der Datenbank auf 10 gesetzt. Geben Sie stattdessen den Wert „+10“ an so wird der Wert auf 110 erhöht, bei „-10“ würde er auf 90 verringert.
Wenn möglich sollten beim Import Differenzen angegeben werden, da es auf diese Weise nie passieren kann, dass durch den Import Änderungen rückgängig gemacht werden die durch den Online-Shop vorgenommen wurden. Bsp.: Sie wollen die Zahl der Bonuspunkte eines Kunden von 150 auf 100 heruntersetzen, weil er über eine telefonische Bestellung 50 Punkte eingelöst hat. Derselbe Kunde war kurz bevor Sie den Import gestartet haben im Shop und hat eine Bestellung abgeschickt, durch die ihm zusätzliche 77 Punkte gutgeschrieben wurden. Importieren Sie nun „100“ so löschen Sie damit die Gutschrift von 77 Punkten. Importieren Sie dagegen „-50“, so wird die Zahl der Bonuspunkte auf den korrekten Wert (177) gesetzt.Ein explizites Löschen von Einträgen aus der Kundenkonto-Tabelle ist nicht möglich, Einträge werden dann gelöscht, wenn (durch Übertragen der Datei „custdelete.csv”) die allgemeinen Kundendaten gelöscht werden. Sie können natürlich die Werte auf "0" setzen.
Bei einem Import können mehrere Dateien mit Kundenkonten, Bonuspunkte und Zuschüsse importiert werden. In diesem Fall müssen die Namen mit einem „Suffix“ versehen werden, der Name einer Importdatei könnte dann z. B. „accountupdate_1.csv“ lauten.
Der Suffix beginnt mit einem Unterstrich, gefolgt von einer oder mehreren Ziffern.
Die Importdateien werden vor dem Import alphanumerisch sortiert, d. h. „accountupdate_10.csv“ wird vor „accountupdate_2.csv“ importiert.
Angebotsdaten
Mit dieser Funktion können Sie ein Angebot, das Sie einem bestimmten Kunden gemacht haben, in den Online-Shop übertragen, der Kunde kann die entsprechenden Produkte dann online bestellen.
Für den Import von Angebotsdaten müssen Sie zwei Dateien erstellen, die Datei „offerheadupd.dat“ und die Datei „offerprodupd.dat“. Die erste Datei enthält Daten die das gesamte Angebot betreffen, z. B. die Versandkosten. In der zweiten Datei sind die einzelnen Produkte des Angebots enthalten.
Löschen können Sie Angebote mit der Datei „offerdel.dat“.
Alle drei Dateien müssen im „data-exchange“ Verzeichnis abgelegt werden. Alternativ können die Dateien auch „offerheadupd.csv“, „offerprodupd.csv“ und „offerdel.csv“ benannt werden, in diesem Fall müssen sie im Verzeichnis der Kunden-Importdateien („customerimport“) gespeichert werden.
Bei einem Import über die SFTP-SOAP-Schnittstelle müssen die *.csv Dateien verwendet werden, bei einer Übertragung mit dem WSPManager können die *.dat oder die *.csv Dateien benutzt werden.
Aufbau der Datei offerheadupd.dat/offerheadupd.csv
Feldname | Feldinhalt | Beschränkung |
|---|---|---|
Subshop | Die ID des Subshops in dem das Angebot angezeigt werden soll | max. 128 Zeichen |
CustomerID | Die Kundennummer | max. 255 Zeichen |
OfferID | Eine eindeutige ID für das Angebot | max. 255 Zeichen |
ExpireDate | Datum bis zu dem das Angebot gültig ist im Format TT.MM.JJJJ |
|
OfferDate | Datum zu dem das Angebot abgegeben wurde im Format TT.MM.JJJJ |
|
PaymentCode | Code der Zahlungsart |
|
PaymentCost | Kosten der Zahlungsart (z. B. Nachnahmegebühr) |
|
DeliveryName | Name des Zustellers (z. B. „Post innerhalb Deutschland,“) |
|
Deliverycost | Versandkosten |
|
Description | Beschreibung | max. 4000 Zeichen |
Aufbau der Datei offerprodupd.dat/ offerprodupd.csv
Feldname | Feldinhalt | Beschränkung |
|---|---|---|
CustomerID | Die Kundennummer | max. 255 Zeichen |
OfferID | Die ID des Angebots | max. 255 Zeichen |
Name | Name des Produkts | max. 128 Zeichen |
Insert | Werbemittelcode | max. 16 Zeichen |
Number | Produktnummer | max. 64 Zeichen |
Quantity | Anzahl |
|
Price | Preis | max. 9 Zeichen |
VAT | Mehrwertsteuerindex |
|
DiscountRate | Rabatt in Prozent |
|
Discount | Rabatt (Absolutbetrag) |
|
Variations | Variation des Produkts im Format Bsp: |
|
TextinputFields | Texteingabefelder des Produkts im Format Bsp: |
|
Upload | „X“: Der angebotene Artikel ist ein „Upload-Artikel“ |
|
Image | Der Dateiname eines normalgroßen Bildes, das zusammen mit dem Angebot angezeigt werden kann. Die zugehörige Datei muss im Shop im Verzeichnis „...\produkte\medien\bilder\normal“ abgelegt werden. | max. 128 Zeichen |
Thumbnail | Der Dateiname eines kleinen Bildes, das zusammen mit dem Angebot angezeigt werden kann. Die zugehörige Datei muss im Shop im Verzeichnis „...\produkte\medien\bilder\klein“ abgelegt werden. | max. 128 Zeichen |
ProdOrder | Ein ganzzahliger, positiver Wert, der die Reihenfolge festlegt, in der die Produkte des Angebots angezeigt werden. Ein Produkt mit einem kleineren „ProdOrder“-Wert wird vor einem Produkt mit einem größeren „ProdOrder“-Wert angezeigt. Fehlt dieses Feld, so werden die Produkte in der Reihenfolge angezeigt, in der sie in der Importdatei stehen. | 8 Zeichen |
Aufbau der Datei offerdel.dat/ offerdel.csv
Feldname | Feldinhalt | Beschränkung |
|---|---|---|
CustomerID | Die Kundennummer | max. 255 Zeichen |
OfferID | Die ID des Angebots | max. 255 Zeichen |
Import von kundenabhängigen Bestellmengen
Für jedes Produkt und jeden Kunden kann eine maximale und/oder eine minimale Bestellmenge importiert werden.
Das Anlegen und Ändern von Bestellmengen erfolgt über die Importdatei „orderquantityupdate.csv“, das Löschen über die Datei „orderquantitydelete.csv“. Beide Dateien dürfen eine maximale Größe von 1 GB nicht überschreiten und beide müssen (wie die übrigen Kundenimportdateien) im Verzeichnis „customerimport“ angelegt werden.
Die Datei „orderquantitydelete.csv“ wird vor der Datei „orderquantityupdate.csv“ eingelesen, so dass es möglich ist bei einem Import Einträge zu löschen und wieder neu anzulegen.
Aufbau und Inhalt der Datei orderquantityupdate.csv
Die Datei dient zum Anlegen und Ändern von Einträgen und enthält folgende Felder:
Feldname | Feldinhalt | Beschränkungen/ | Pflichtfeld ja/nein |
|---|---|---|---|
CustomerID | Die Kundennummer | max. 255 Zeichen | ja |
ProdIndex | Der Produktindex | max. 64 Zeichen | ja |
Subshop | Der Subshop des Produkts | max. 128 Zeichen | ja |
MaxOrderQuantity | Die maximale Bestellmenge | Fließkommazahl | nein |
MinOrderQuantity | Die minimale Bestellmenge | nein |
Bemerkungen:
Der Wert "-" in den Feldern "MaxOrderQuantity" und "MinOrderQuantity" bewirkt, dass der im Shop gesetzte Wert nicht verändert wird. Das Feld komplett leer zu lassen, hat den gleichen Effekt.
Der Wert "$NoLimit$" in den Feldern "MaxOrderQuantity" oder "MinOrderQuantity" bewirkt, dass ein gesetztes Limit für das Produkt/den Kunden aufgehoben wird. D. h. der Kunde kann danach beliebig viel oder beliebig wenig von dem Produkt bestellen.
Wenn für ein Produkt/einen Kunden noch nie explizit ein Wert für MinOrderQuantity oder MaxOrderQuantity gesetzt wurde, so entspricht der Wert "$NoLimit$".
"$NoLimit$" ist also der Wert, mit dem die Felder "MaxOrderQuantity" und "MinOrderQuantity" initialisiert werden.Wenn für kein Produkt/keinen Kunden eine maximale/minimale Bestellmenge gesetzt werden soll, so kann die Spalte MaxOrderQuantity/MinOrderQuantity komplett weggelassen werden. Der Effekt ist der gleiche, als ob die Spalte mit dem Wert "-" gefüllt wäre.
Beim Löschen von Produkten oder Kunden werden die zugehörigen Bestellmengen nicht automatisch gelöscht. Ein Automatismus ist problematisch, wenn Produkte oder Kunden gelöscht und danach wieder neu angelegt werden, weil danach auch die Bestellmengen neu importiert werden müssten.
Es erfolgt keine Prüfung, ob ein Kunde oder ein Produkt in der Importdatei tatsächlich im Shop existiert. Dies hat den Vorteil, dass Bestellmengen vor den Produkten oder Kunden importiert werden können.
Bei Produkten mit abhängigen Variationen reicht es nicht, für den Stammartikel eine Bestellmenge anzugeben. Stattdessen muss die Bestellmenge für jede einzelne abhängige Variation angegeben werden.
Wenn ein Kunde im Shop bestellt, so wird der Wert von MaxOrderQuantity um die bestellte Menge verringert.
Aufbau und Inhalt der Datei orderquantitydelete.csv
Die Datei dient zum Löschen von Einträgen und enthält folgende Felder:
Feldname | Feldinhalt | Beschränkungen/ | Pflichtfeld |
|---|---|---|---|
CustomerID | Die Kundennummer | max. 255 Zeichen | ja |
ProdIndex | Der Produktindex | max. 64 Zeichen | ja |
Subshop | Der Subshop des Produkts | max. 128 Zeichen | ja |
Bemerkungen:
Für jede Spalte kann der Spezialwert "*" angegeben werden. Dieser bewirkt, dass der Wert in dieser Spalte beim Löschen nicht berücksichtigt wird. Steht z. B. in der Spalte "ProdIndex" der Wert "123", in der Spalte "Subshop" der Wert "deutsch" und in der Spalte CustomerID der Wert "*", so würden die Bestellmengen des Produkts "123" für alle Kunden gelöscht werden
Import von Prime-Paketen
Die einem Kunden zugewiesenen Prime-Pakete werden über die Dateien primeupdate.csv und primedelete.csv importiert.
Aufbau der Datei primeupdate.csv
Die Datei primeupdate.csv dient zum Anlegen und Aktualisieren der einem Kunden zugewiesenen Prime-Pakete. Jedem Kunden können maximal 10 unterschiedliche Prime-Pakete zugewiesen werden.
Wird für einen Kunden ein Prime-Paket importiert, das diesem bereits zugewiesen ist, so werden die Daten des vorhandenen Prime-Paketes aktualisiert. Ist ihm das Prime-Paket noch nicht zugewiesen, so wird es hinzugefügt.
Prime-Pakete, die dem Kunden zugewiesen sind, aber nicht importiert werden, bleiben unverändert erhalten.
Jede Zeile der Import-Datei entspricht einem Prime-Paket, d. h. wenn einem Kunden 10 Prime-Pakete zugewiesen werden sollen, dann muss die Datei 10 Zeilen für diesen Kunden enthalten.
Die Datei primeupdate.csv enthält folgende Felder:
Feldname | Feldinhalt | Beschränkungen/ | Pflichtfeld ja/nein |
|---|---|---|---|
CustomerID | Die Kundennummer | max. 255 Zeichen | ja |
UserIndex | Wenn ein UserIndex >0 in der Datei angeben ist, so wird dieser statt der Kundennummer zur Adressierung verwendet. Existiert kein Kunde mit diesem UserIndex, so wird der Datensatz ignoriert. | ganzzahliger Wert <2147483647 | nein |
ProdIndex | Der Produktindex des Set-Oberartikels der die Daten des Prime-Paketes enthält | max. 64 Zeichen | ja |
ValidFrom | Der Beginn der Gültigkeit im Format YYYYMMDD | max. 8 Zeichen | ja |
ValidUntil | Das Ende der Gültigkeit im Format YYYYMMDD | max. 8 Zeichen | ja |
Cancel | „yes“: Kündigung gewünscht | max. 3 Zeichen | nein |
OrderInfo | Beliebige Daten, die in der Bestellung für das Paket zurückgegeben werden sollen. „-“: Wert in den Kundendaten nicht überschreiben | max. 256 Zeichen | nein |
Aufbau der Datei primedelete.csv
Die Datei primedelete.csv dient zum Löschen von Prime-Paketen, die einem Kunden zugewiesen sind. Sie enthält folgende Felder:
Feldname | Feldinhalt | Beschränkungen/ | Pflichtfeld ja/nein |
|---|---|---|---|
CustomerID | Die Kundennummer | max. 255 Zeichen | ja |
UserIndex | Siehe oben “primeupdate.csv” | ganzzahliger Wert <2147483647 | nein |
ProdIndex | Der Produktindex des Set-Oberartikels, der die Daten des Prime-Paketes enthält oder der Wert „*“, wenn alle Prime-Pakete eines Shops gelöscht werden sollen. | max. 64 Zeichen | ja |
Beispieldateien
Teil dieser Dokumentation sind folgende Beispieldateien, die Sie auf der untergeordneten Seite zum Download finden:
Verzeichnis | Kommentar |
|---|---|
Angebot | Beispiel für den Import von Angebotsdaten |
Kundenkonto | Beispiel für den Import von Kundenkonto/Bonuspunkten/Zuschüssen |
Pkundengrp | Beispiel für den Import von Produktkundengruppen |