Bestandskunden - Benutzer

Guten Tag, wir haben folgendes Problem:

  1. Migration von Bestandskunden in einen neuen Oxid Shop
    Wir wollen Bestandskunden neu in einen Shop migrieren. Der Kunde selbst sollte nicht bemerken, dass er registriert ist, da wir die internen (Vertreter) Bestellungen ebenfalls über den Shop abwickeln (http://www.oxid-esales.com/en/exchange/extensions/backend-bestellung). Wenn sich der Kunde aber doch registrieren will, dann sollte er nicht bemerken, dass er schon registriert war und die neuen Daten, die er eingibt, sollten einfach in den Feldern überschrieben werden.
    Momentan funktioniert es soweit, dass der Kunde, sobald er sich registriert, obwohl er schon existiert, eine neue Kundennummer (inc) zugeteilt bekommt, und der Bestandskunde verschwindet (wird überschrieben). Auch Settings wie z.b. Zahlungsart werden auf Default zurückgesetzt. Ob die Bestellhistorie etc. verschwindet, konnte ich noch nicht testen.

mfg. Michael

Guten Tag, hat niemand das Problem, dass er den Shop zugleich für interne Bestellungen und Shopbestellungen verwendet? Was ist wenn sich ein Bestandskunde über den Shop nochmals anmeldet?

Er bekommt eine neue Kundennummer, ist das sinnvoll?

Vielen Dank für irgendeine Antwort :slight_smile:

Hmm, ich glaub die Antwortlosigkeit liegt eher in der Formulierung der Frage. ohne deinen zweiten Post habe ich nicht herauslesen können, worum es dir geht.
Aber hier mal ein paar Gedanken zu dieser Thematik:
Wenn ein Kunde über den Vertreter kauft ist er Kunde warum sollte er dann nicht auch als solcher behandelt werden ? Irgendwie so formuliert: “Als unser truer Kunde haben Sie als einer der ersten exklusiven Zugang zu unseren neuen tollen Angeboten aus unserem neuen Onlineshop! Ihre persönlichen Zugangsdaten lauten xxx. Besuchen sie uns es lohnt sich, die ersten 200 Käufer erhalten ein Schlüsselband gratis geschenkt”

Das zum logischen Hintergrund. Wie wollt ihr denn die Überprüfung durchführen ob der Neuregistrierte bereits Bestandskunde ist? eMail? Dann sollte es kein Problem sein die Registrierungsroutine in soweit anzupassen, dass keine Meldung raus geht “Bereits registriert” sondern die Registrierung vonstatten geht. Wenn sich jetzt aber durch einen Vertipper mü[email protected] als mü[email protected] bei euch anmeldet, überschreibt er dann auch euren Bestandskunden der den selben Nachnamen trägt aber im anderen Jahrzehnt geboren wurde? Und kann ich dann einfach jemandes Daten ändern indem ich einfach seine Emailadresse beim Registrierungsprozess benutze?Aber auch unterschiedliche Emailadressen sei’s durch Provider wechsel oder durch Erschließung neuer Dienste führt zu Inkonsistenzen.

Ich würde die Shop Eröffnung offen kommunizieren.

Grüße

Rafael

PS.: Und wenn Ihr die Daten eh nicht haben sollen dürftet, solltet ihr vllt. mal da anfangen, anstatt versuchen diesen Sachverhalt zu vertuschen :wink:

Guten Tag, danke mal für deine Antwort.

Ich bitte dich zuallererst, ohne die Hintergründe zu kennen, nicht zu unterstellen, dass wir hier etwas Illegales durchführen wollen, genauso wenig wollen wir etwas vertuschen.

Hier geht es um Workflowoptimierung. Der Kunde arbeitet z.Zt. mit einem Warenwirtschaftssystem. hauptsächlich Geschäftskunden, Öffentliche Hand, etc.
Die Überlegung geht in die Richtung, die Warenwirtschaft durch den Shop abzulösen. Wir wollen das Backend Order Modul von Aggrosoft einsetzen.

Wenn wir nun den Kunden anlegen, um Backendorders von Vertretern durchführen zu lassen, muss der Kunde angelegt werden. Es gibt Kunden, die nur von Vertretern bedient werden. Die Shoperöffnung wird auch kommuniziert. Es gibt allerdings Kunden, die weiterhin nur über Vertreter bedient werden wollen. Diese sollten allerdings auch mit Newslettern, etc. bedient werden können, die auch über den Shop abgewickelt werden. Also muss die Emailadresse stimmen.
Wir können allerdings nicht verhindern, dass diese Kunden sich irgendwann dann auch am Shop anmelden. Ist dies der Fall, wird Shopintern 1. eine neue Kundennummer erzeugt, die alte gelöscht (überschrieben), die ganze Historie des Kunden gelöscht (überschrieben).

Auch wenn es eine zweite Kundennummer (durch Verwendung von Dummyemailadressen) geben würde, wäre dies unpraktisch, da der Kunde dann zwei Mal existieren würde (Buchhaltung, Stammdaten, Historie, etc…)

Darum wäre der Idealfall, dass auf Basis der Emailadresse als Unique Identifier die Angaben des Kunden einfach aktualisiert würden, auf dem existierenden Stammdatensatz, und er einfach ein Passwort zugesendet bekäme.

Das unser Problem,

mfg Michael

Hi,

so eine ähnliche Diskussion gab es schonmal bei Bestellungen mit und ohne Kundenkonto. Wenn du es ohne Kundenkonto machst hast du die von dir beschriebene Problematik.
Wenn du für jeden Kunden ein Kundenkonto mit Passwort hast kann ja trotzdem jeder deiner Vertreter über das Backend eine Bestellung eingeben. Ein “Call Center Modul” macht ja nichts anderes wie deine Vertreter. Wenn der Kunde jetzt doch mal selbst bestellen möchte kann er die Passwort vergessen funktion verwenden, wenn er sein Passwort nicht kennt bzw. du es ihm nicht mitgeteilt hast.
Ein Kunde mit Kundenkonto kann auf seine Emailadresse auch keine 2 Accounts anlegen.

cya

Darum wäre der Idealfall, dass auf Basis der Emailadresse als Unique Identifier die Angaben des Kunden einfach aktualisiert würden, auf dem existierenden Stammdatensatz, und er einfach ein Passwort zugesendet bekäme.

Das Problem ist, dass man sich einfach mit einer fremden Mailadresse anmelden könnte und die Daten überschreiben und die Historie einsehen könnte. Im Standard ist es in der neuen Version so, dass eine Fehlermeldung angezeigt wird, wenn sich ein Kunde mit einer existierenden Adresse anmelden will. Diese Fehlermeldung könnte man nutzen, um dem Kunden mitzuteilen, dass bereits ein Konto existiert, und kann ihm auch gleich die “Passwort vergessen” Funktion anbieten. Das könnte man noch optimieren indem man ihn zuerst nur die e-Mail Adresse eingeben lässt, und dann auf das Registrierformular weiterleitet wenn die Adresse nicht vorhanden ist, oder auf die Passwort vergessen Funktion wenn die Adresse schon existiert.