Format und Inhalt - WS-SFTP-Kunden PRO (DE)
- René Meyer
- Jakub Kawa
- Rainer Biedermann (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 | (Rabattgruppierung) 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-100 | 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 |
© 2025 WEBSALE AG | Impressum | Datenschutz