> ## Documentation Index > Fetch the complete documentation index at: https://dokumentation.websale.de/llms.txt > Use this file to discover all available pages before exploring further. # Adressierung der Datensätze > Wie Shop und Warenwirtschaft Kundendatensätze einander zuordnen: UserIndex, CustomerID, TableIndex und ExternalID, die Regeln für Neuanlage und Update sowie die Sonderfälle Mehrfachkonten und Mail-Adressierung. Damit Warenwirtschaft und Shop denselben Kunden meinen, brauchen beide Seiten Schlüsselfelder. Einige davon verwaltet der Shop, andere die Warenwirtschaft, eines der Kunde selbst. Wer diese Aufteilung versteht, vermeidet die häufigsten Importfehler. Zu einem Kunden gehören einfach vorkommende Daten wie Name und Anschrift, dazu mehrfach vorkommende Datensätze, die sogenannten multiplen Kundenzusatzdaten. Das sind Lieferadressen und Bankverbindungen. ## Die Schlüsselfelder ### E-Mail-Adresse Die primäre Identifikation eines Kunden erfolgt im Shop immer über seine E-Mail-Adresse. Ein Neukunde ist aus Sicht des Shops jemand, der sich mit einer bisher keinem Konto zugeordneten Adresse ein neues Konto anlegt. ### UserIndex, vom Shop verwaltet Der UserIndex ist eine eindeutige, numerische ID. Er wird ausschließlich vom Shop vergeben, und zwar nur bei der Neuanlage eines Kundendatensatzes in der Shop-Datenbank. Das passiert in zwei Fällen: Ein Neukunde registriert sich im Shop, oder die Warenwirtschaft übergibt einen dem Shop bisher unbekannten Datensatz. Um einen vorhandenen Datensatz zu aktualisieren, adressiert die Warenwirtschaft ihn über den UserIndex. ### CustomerID, von der Warenwirtschaft verwaltet Die CustomerID ist aus Sicht des Shops nur eine Zeichenkette. Üblicherweise ist es die Kundennummer, die die Warenwirtschaft erzeugt hat. Hier liegt eine Pflicht, die gern übersehen wird: Liest Ihre Warenwirtschaft einen neuen Kundendatensatz aus dem Shop ein und vergibt dafür eine neue Kundennummer, muss sie diese Nummer dem Shop zurückmelden. Als UserIndex übergibt sie dabei den Wert, den sie mit der Bestellung oder dem Kundendatensatz erhalten hat. Existiert die Kundennummer im Shop bereits, lehnt der Import sie als Dublette ab. ### TableIndex und ExternalID der multiplen Kundenzusatzdaten Diese beiden IDs adressieren Datensätze, die je Kunde mehrfach vorkommen können, also Lieferadressen und Bankverbindungen. Für jeden dieser Datentypen führt der Shop eine eigene Tabelle. Den **TableIndex** vergibt ausschließlich der Shop, und zwar bei der Neuanlage eines Datensatzes in einer dieser Tabellen. Er ist innerhalb seiner Tabelle eindeutig, aber nicht darüber hinaus. Eine Lieferadresse kann den TableIndex `123` tragen und gleichzeitig eine Bankverbindung eines ganz anderen Kunden ebenfalls. Ein TableIndex ist deshalb nur zusammen mit der Angabe, um welche Tabelle es geht, aussagekräftig. Die **ExternalID** ist wieder nur eine Zeichenkette aus Sicht des Shops, üblicherweise ein Index, mit dem die Warenwirtschaft beispielsweise eine von mehreren Lieferadressen referenziert. ## Regeln für Neuanlage und Update ### Neuanlage eines Kundenstammdatensatzes Kennzeichen einer Neuanlage ist ein leeres Feld `UserIndex`. Die Warenwirtschaft übergibt eine neue CustomerID und eine im Shop noch nicht bekannte E-Mail-Adresse. Beim Import vergibt der Shop einen neuen UserIndex und meldet ihn über eine Export-Schnittstelle zurück, siehe [SOAP-from-Shop](https://dokumentation.websale.de/v8s/schnittstellen/uebertragung/soap-from-shop.md). Eine Dublette wird abgelehnt und der Datensatz verworfen. Als Dublette gilt ein Datensatz, dessen CustomerID oder E-Mail-Adresse bereits in der Shop-Datenbank steht. Beide müssen also neu sein. Name und Anschrift spielen für die Dublettenprüfung keine Rolle. ### Update eines Kundenstammdatensatzes Kennzeichen eines Updates ist ein `UserIndex`, der im Shop existiert. Die Warenwirtschaft übergibt dabei sämtliche Felder des Datensatzes, nicht nur die geänderten. ### Multiple Kundenzusatzdaten Bei der Neuanlage dürfen gleiche E-Mail-Adressen für unterschiedliche Konten übergeben werden. Die CustomerID muss jedoch eindeutig sein und darf im Shop noch nicht existieren, sonst wird der Datensatz verworfen. Ein Update läuft wie beim Kundenstammdatensatz über den UserIndex. ## Zwei Beispiele ### Neukunde registriert sich selbst im Shop Der Shop legt den Datensatz an und vergibt einen UserIndex, beispielsweise `123456`. Diesen übergibt er zusammen mit den übrigen Stammdaten an die Warenwirtschaft, entweder gemeinsam mit den Bestelldaten, wenn der Kunde bestellt hat, oder über die Adressänderungsdaten, wenn nicht. Das Feld `CustomerID` bleibt dabei leer, denn der Shop kennt noch keine Kundennummer. Ihre Warenwirtschaft muss dieses leere Feld auswerten und daran erkennen, dass es sich um einen neuen Shopkunden handelt. Sie vergibt dann eine Kundennummer, beispielsweise `777888`, und repliziert sie umgehend zurück: in der Importdatei den Kunden über den UserIndex `123456` adressieren und die neue Kundennummer übergeben. ### Neukunde wird in der Warenwirtschaft angelegt Für den Import sind zwei Felder Pflicht: eine neue Kundennummer und eine neue E-Mail-Adresse. Der UserIndex muss leer oder `0` sein. Am fehlenden UserIndex erkennt der Shop die Neuanlage. Er prüft, ob CustomerID oder E-Mail bereits existieren, und legt bei negativem Ergebnis einen Datensatz mit neuem UserIndex an. Die vergebenen Userindizes fragen Sie anschließend über die SOAP-Funktion `GetAddedCustomers` ab, siehe [SFTP-SOAP-to-Shop](https://dokumentation.websale.de/v8s/schnittstellen/uebertragung/sftp-soap-to-shop.md). ## Sonderfall: Datensätze aus dem eMarketingManager Nicht nur der Shop legt Kundendatensätze an, auch der eMarketingManager tut das. Weil für einen Newsletter in der Regel die E-Mail-Adresse genügt, haben diese Datensätze üblicherweise kein Passwort. Und weil viele Warenwirtschaften einen Datensatz, der nur aus einer E-Mail-Adresse besteht, verwerfen, haben sie meist auch keine Kundennummer. Daraus entsteht ein Problem: Soll später ein vollständiger Datensatz mit derselben Adresse importiert werden, kennt die Warenwirtschaft dessen UserIndex nicht. Der Import als Neuanlage würde an der bereits vergebenen E-Mail-Adresse scheitern. Deshalb zieht der Shop unter zwei Bedingungen zusätzlich die E-Mail-Adresse zur Adressierung heran: * In den Importdaten steht kein UserIndex, aus Sicht der Warenwirtschaft handelt es sich also um eine Neuanlage. * In der Shop-Datenbank existiert ein Kunde mit dieser E-Mail-Adresse, und zwar ohne angelegtes Passwort und ohne Kundennummer. Sind beide erfüllt, schreibt der Import die Daten in genau diesen Datensatz. Unter Datenschutzgesichtspunkten ist das vertretbar, weil der Besitzer der Adresse bei der Newsletter-Registrierung ein Double-Opt-In durchlaufen musste und damit die Berechtigung zur Nutzung der Adresse nachgewiesen hat. ## Sonderfall: Mehrfachkonten über die E-Mail-Adresse Standardmäßig lässt sich je E-Mail-Adresse genau ein Konto anlegen. Mit dem Feature Mehrfachkonten sind mehrere Konten mit derselben Adresse möglich, jedes mit eigenem Passwort. Ein typischer Anwendungsfall aus dem B2B-Bereich: Eine Einkaufsabteilung wickelt ihre gesamte Kommunikation über eine zentrale Adresse wie `einkaufsteam@firma.de` ab, trotzdem soll jede Bestellung einem einzelnen Einkäufer zuzuordnen sein. Die Anmeldung erfolgt dann mit derselben Adresse, aber unterschiedlichen Passwörtern. Setzen Sie das Feature nur im Ausnahmefall ein. Doppelte E-Mail-Adressen schränken etliche Shopfunktionen ein oder machen sie unmöglich. Die Nutzung erfordert eine spezielle Konfiguration durch die WEBSALE AG. ## Sonderfall: Mehrfachkonten über die CustomerID Normalerweise lassen sich über den Import keine zwei Kundendatensätze mit derselben Kundennummer anlegen, sie würden als Duplikate abgelehnt. Das Feature Mehrfachkonten (CustomerID) hebt diese Beschränkung auf. Dabei entsteht eine zusätzliche Schwierigkeit: Die Datensätze in den einzelnen Importdateien, beispielsweise `custupdate.csv` und `billcomplete.csv`, werden über UserIndex oder CustomerID verknüpft. Bei einer Neuanlage muss der UserIndex aber `0` sein, und bei mehrdeutigen Kundennummern ist dann keine eindeutige Zuordnung der Zeilen mehr möglich. Deshalb muss bei diesem Feature in jeder Importdatei zusätzlich das Feld `Email` stehen. Aus demselben Grund lassen sich Mehrfachkonten über CustomerID und über E-Mail nicht kombinieren. ## Sonderfall: Mail-Adressierung Normalerweise lehnt der Import einen Datensatz mit leerem UserIndex als Dublette ab, wenn dessen E-Mail-Adresse bereits vergeben ist. Bei aktivierter Mail-Adressierung überschreibt er stattdessen den vorhandenen Datensatz. Dasselbe passiert, wenn der übergebene UserIndex im Shop nicht existiert: Der Import sucht dann nach der E-Mail-Adresse und überschreibt den gefundenen Datensatz. Der Vorteil ist Fehlertoleranz. Legt ein Sachbearbeiter einen Kunden in der Warenwirtschaft an, der sich zwischenzeitlich selbst im Shop registriert hat, scheitert der Import sonst. Ebenso bleibt ein Import möglich, wenn in der Warenwirtschaft ein veralteter UserIndex steht, beispielsweise weil der Kunde sich im Shop gelöscht und neu registriert hat. Der Nachteil ist dieselbe Fehlertoleranz. Sie verschleiert Abweichungen zwischen beiden Datenbanken. Ein Sachbearbeiter kann durch eine Neuanlage einen vorhandenen Shop-Datensatz überschreiben, ohne dass ihn irgendetwas darauf hinweist. Stimmt der UserIndex in der Warenwirtschaft nicht mehr, lassen sich unbemerkt die Daten eines Kunden überschreiben, für den die Änderung gar nicht gedacht war. Mehrfachkonten über die E-Mail-Adresse lassen sich mit der Mail-Adressierung nicht kombinieren. Auch dieses Feature erfordert eine spezielle Konfiguration durch die WEBSALE AG. ## Verwandte Themen * Wegweiser: [WS-SFTP-Kunden PRO](https://dokumentation.websale.de/v8s/schnittstellen/kundendaten/ws-sftp-kunden-pro.md) * Wegweiser: [Import-Dateien](https://dokumentation.websale.de/v8s/schnittstellen/kundendaten/ws-sftp-kunden-pro/import-dateien.md) * Wegweiser: [SOAP-from-Shop](https://dokumentation.websale.de/v8s/schnittstellen/uebertragung/soap-from-shop.md) ## Related topics - [Weitere Import-Dateien](https://dokumentation.websale.de/v8s/schnittstellen/kundendaten/ws-sftp-kunden-pro/weitere-import-dateien.md) - [Import-Dateien](https://dokumentation.websale.de/v8s/schnittstellen/kundendaten/ws-sftp-kunden-pro/import-dateien.md) - [WS-SFTP-Kunden PRO](https://dokumentation.websale.de/v8s/schnittstellen/kundendaten/ws-sftp-kunden-pro.md) - [API-Referenz Produkte](https://dokumentation.websale.de/schnittstellen/admin-interface-api/api-referenz-produkte.md) - [SOAP-from-Shop](https://dokumentation.websale.de/v8s/schnittstellen/uebertragung/soap-from-shop.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.