[elf4]

Guten Abend,

wir haben in unseren Shop die Option einen Kauf als Gast zu betätigen ohne sich registrieren zu müssen. Weiterhin ist unser Shop am SAP angebunden und exportiert jede Bestellung mit Bestellnr und Kundennr. wobei Gäste auch Kundennr. bekommen. Nun kommt es nicht selten vor, dass ein Gast der bereits mit Gastaccount bestellt hat erneut mit neuen Gastaccount bestellt. Nun beginnt das ganze Schlamassel.

Folglich wird die neue Bestellung ins SAP importiert und der Kunde ist im SAP 2 mal geführt mit unterschiedlichen Kundennummern. Wie kann man dies am besten Handhaben das dies in Zukunft nicht mehr passiert.

Wie handhabt ihr das?

Unsere erste Idee war es nun das Exportscript anzupassen und doppelte Gastaacounts zu vergleichen und bei einer Übereinstimmung von x Prozent jene Account den ersten Gastaccount unterzuordnen. Das Problem dabei ist nur das es zum Beispiel in Dörfern vorkommen kann das 3. Generationen in der gleichen Straße und Hausnummer wohnen oder Email Adressen variieren können. Auch denkbar wäre es das der Kunde umgezogen ist und deshalb unterschiedliche Anschriften hat.

Eins muss man noch erwähnen:

Als Gast muss man beim Kauf lediglich Vorname, Nachname und Anschrift angeben. Geburtsdatum und Telefon sind optional.

Gibt es noch einen anderen Ansatz um doppelte Kundenführung im SAP zu vermeiden?

[Diversity]

Ihr könntet den Kunden auch im Formular fragen, ob er schon mal bestellt hat...

[faust1970]

Hmm, zunächst einmal finde ich es nicht wirklich o.k dem Kunden vorzugaukeln es werden keine Kundendaten angelegt und dann wird er doch dauerhaft gespeichert. Demnach sieht mein Vorschlag so aus das Ihr die Kundendaten für Gastbesteller nach Versand löscht und nur die eigentliche Bestellung, sortiert nach Best.Nr. speichert. So habt Ihr die Best. vorliegen wenn Retouren/reps. u.ä anfällt.
Im SAP sehe das dann so aus das es ein Register innerhalb der Kundendatenbank das nur Best. Daten der "Neulunden/Gastkunden/Einzelbesteller" beinhaltet.
Weiterhin frage ich mich allerdings:
1. Wozu diese Sonderfunktion?-> zumal mehr als unüblich heutzutage
2. -> siehe einen drüber: wieso fragt Ihr nicht?
3. Wie groß ist, prozentual die Anzahl der Gastbesteller gegenüber den registrierten?

F.

[elf4]

Wir gaukeln gar nichts vor. Denn nur die Bestelldaten werden im SAP von Gastkonten gespeichert (wegen Retouren / Garantie). Im Shop ansicht wird kein Gast-Account nach erfolgreicher Bestellung geführt.

Ich versuche nochmal die Problematik ausführlich zu veranschaulichen.

Als registrierter Kunde ist der Status im SAP eindeutig - jeder Kunde wird mit eindeutiger Kundennummer geführt und jede weitere Bestellungen werden dann der Kundennummer zugeordnet. Als Gast ist der Status ein anderer - jeder Gastaccount ist nur einmalig gültig und bekommt eine Kundennummer. Wenn ein Gast nun 2 mal bestellt mit den gleichen Angaben wird er im SAP mit 2 Kundennummern geführt. Dies gilt es optional zu verhindern.

Zudem Fragen: Der Anteil zwischen Gastbestellung und Bestellung mit registrierten Kundenaccount ist bei uns ca. 60% zu 40%. Wir haben die Erfahrung durch A/B Tests gemacht das Kunden die sich nicht registrieren müssen weniger von den Kauf abspringen als jene die sich registrieren. Deswegen bieten wir auch die Option an die Bestellung als Gast durchzuführen.

Ja wir können in der Tat den Kunden bei der Bestellung durch ein weiteres Feld fragen ob er bereits bei uns bestellt hat - dies würde aber erst einmal wenig bringen da man mit der Antwort noch nichts anfangen könnte und es dazu führen würde das der Gastkunde denken könnte das Gastaccounts im Shop nach der Bestellung weitergeführt werden. Dies macht aus Usability Gesichtspunkten wenig Sinn. Auch am Telefon ist der IST-Zustand momentan dieser das man im Fall mehrerer Kunden mit gleichen Namen nach der Bestellnummer fragt - was suboptimal ist.

[undi]

Zitat von elf4

Wenn ein Gast nun 2 mal bestellt mit den gleichen Angaben wird er im SAP mit 2 Kundennummern geführt. Dies gilt es optional zu verhindern.

Wenn ihr Bestellungen ohne Registrierung anbietet werdet ihr das nicht verhindern können. Ihr habt nur die wenigen Daten (Name, Anschrift) die allerdings nicht immer eindeutig sind. Es besteht daher keine Möglichkeit einer sicheren Zuordnung.
Das ist ja genau der Unterschied zwischen einer Registrierung, dass hier ein eindeutiges Benutzerkonto verwendet wird.

Schau doch mal in allen anderen Webshops usw. dort bekommt man als unregistrierter Kunde auch jedes mal eine neue Kundennummer.

Euer Ansatz mag ja wünschenswert sein, aber mit dem Konzept ohne Registrierung wird das nicht sauber klappen.

Ansonsten würde ich dir aber generell empfehlen deine Frage im SDN zu stellen und nicht hier

[elf4]

Danke für die Bestätigung unseres Anfangsverdachts. Im SDN könnte man es auch noch mal ansprechen aber wir wollten vorher mal erfragen wie es andere Shopbetreiber händeln bevor wir mit SAP Kontakt aufnehmen.

Eine Frage bleibt aber offen - wäre eine Verbindung von Gastdaten nach Filterung ein guter Ansatz oder ist dies wegen einer möglichen Fehlerquote (wenn mit auch niedrigen Wahrscheinlichkeit) ein abzuratener Schritt?

Denn nach internen Vergleichen hat sich herrausgestellt das alle die wiederholt als Gast bestellt haben sich zu 100% matchen lassen - folglich mit gleichen Angaben erneut bestellen.

[undi]

Zitat von elf4

Eine Frage bleibt aber offen - wäre eine Verbindung von Gastdaten nach Filterung ein guter Ansatz oder ist dies wegen einer möglichen Fehlerquote (wenn mit auch niedrigen Wahrscheinlichkeit) ein abzuratener Schritt?

Unabhängig wie man es jetzt realisiert würde ich erstmal die Bestellprozesse analysieren.

Eine Internet Bestellung ohne Registrierung ist ja im Prinzip genau das gleiche wie eine Bestellung früher über das Telefon. Der Besteller gibt seine Daten durch und was er bestellen möchte.

Früher hat hier dann halt die Mitarbeiterin geschaut ob ein Kunde schon vorhanden ist und hat dann einfach eine Bestellung hinzugefügt.
Über das Internet fällt der Mitarbeiter der die Bestellung entgegen nimmt aber erstmal weg.

D.h. man könnte jetzt z.B. einen Algorithmus implementieren, der Vergleicht mit bestehenden Accounts und dann die Bestellung dem bestehenden Account zuweist.
Nachteil wäre hier aber dass es Fehleranfällig ist und der Besteller nicht die Exaktheit bestätigen kann.

Eine Mögliche Lösung wäre, dass der Besteller z.b. seine Daten eingibt und dann gefragt wird, ob der ermittelte Datensatz mit ihm überein stimmt.

Hier würde sich jetzt eventuell der Benutzer wundern, warum ihr seine Daten habt. Allerdings ist es ja keine Anonyme Bestellung, sondern eher wie eine telefonische Bestellung und da ist man sich ja eigentlich schon im klaren, dass die Firma die Daten speichern muss, auch wegen Rückgabe, Garantie usw.

Also es sind ein paar Punkte die ihr Analysieren müsst oder eventuell auch den Bestellprozess analysieren/verändern, um hier eine optimale Lösung zu erzielen.

Dass die Zuordnung zu 100% klappt hört sich gut an, aber wenn im produktiven Betrieb einem Kunden villeicht doch mal falsche Bestellungen zugeordnet werden wäre das halt sehr schlecht.

Ich denke aber bei SAP gibt es da sicher einen use case dafür, den ihr verwendet könnt.

[elf4]

Vielen Dank für den (Denk)Ansatz mit Livezeitprüfung - ich werde morgen noch einmal den Prozess analysieren und visualisieren und schauen ob es im SDN dazu ein HowTo gibt und ggf nochmal Kontakt mit denen aufnehmen. Du hast mir ein Teil die Augen geöffnet - manchmal ist man einfach Fachblind und sieht den Wald vor lauter Bäumen nicht.

Nochmals Danke

[ketza]

Hallo,

folgender Vorschlag / Denksansatz meinerseits:
Warum wird bei Gastbestellungen überhaupt eine Kundennummer/CustomerID angelegt?
Ich denke (wissen tuhe ich es nicht), lediglich die Bestellnummer muss unique sein. Daher würde ich einen statischen Wert für die Auftragsnummer bei Gastbestellungen nutzen.

Eine andere Lösung wäre die Auftragsnummer gleich zu setzen mit der Kundennummer. Sprich im System ist die Auftragsnummer gleich der Bestellnummer (evtl. abhängig gemacht von Gastbestellungen oder Neuregistrierungen).

viele Grüße

[Mamusis]

gibt es eine möglichkeit im customizing zu arbeiten bzw. hat einer von euch ahnung davon ?
unterscheidet ihr nach zahlungsarten bei der bestellung als solches ?

folgendes wird bei uns praktiziert: über den hauseigenen onlineshop wird anfangs differenziert mit welcher zahlungsart der endverbraucher bestellen will. nach übermittlung der bestellung vom shop über die RFC schnittstelle ins SAP gibt es 2 kunden-nr. (eine art sammelnummer). dann gehts ganz normal weiter im modul SD,(teilweise MM),LES dann FI (wobei mein latein nach dem LES aufhört --> bin selber im vertrieb).

wäre sowas vorstellbar ?

[elf4]

Zitat von Mamusis

gibt es eine möglichkeit im customizing zu arbeiten bzw. hat einer von euch ahnung davon ?
unterscheidet ihr nach zahlungsarten bei der bestellung als solches ?

folgendes wird bei uns praktiziert: über den hauseigenen onlineshop wird anfangs differenziert mit welcher zahlungsart der endverbraucher bestellen will. nach übermittlung der bestellung vom shop über die RFC schnittstelle ins SAP gibt es 2 kunden-nr. (eine art sammelnummer). dann gehts ganz normal weiter im modul SD,(teilweise MM),LES dann FI (wobei mein latein nach dem LES aufhört --> bin selber im vertrieb).

wäre sowas vorstellbar ?

2 Fragen dazu:

1)Gibt es bei Euch die Möglichkeit als Gast zu bestellen?
2)Wie ist das bei Euch im Onlineshop mit Gastbestellungen geregelt? Bekommen Gäste jedes Mal eine Kundennummer oder nur einmalig - und wie erkennt Euer System Duplikate im Kundenstamm?

Kannst du noch einmal genauer erklären wie Orders in euren System behandelt werden im Bezug auf den Kundenstamm.

Zu deinen Fragen, wir arbeiten mit mehreren Shopsystemen die sich alle customizen lassen - einmal mit XTC Modified und einmal mit OXID E-Sales Pro. Beim generischer Export der Order (aus den Shop ins SAP) können Zahlungsarten unterschieden werden - diese nutzen wir auch.

Erwähnenswert ist außerdem das wir mit SAP Business One nicht mit SAP R3.

Zitat von ketza

Hallo,

folgender Vorschlag / Denksansatz meinerseits:
Warum wird bei Gastbestellungen überhaupt eine Kundennummer/CustomerID angelegt?
Ich denke (wissen tuhe ich es nicht), lediglich die Bestellnummer muss unique sein. Daher würde ich einen statischen Wert für die Auftragsnummer bei Gastbestellungen nutzen.

Eine andere Lösung wäre die Auftragsnummer gleich zu setzen mit der Kundennummer. Sprich im System ist die Auftragsnummer gleich der Bestellnummer (evtl. abhängig gemacht von Gastbestellungen oder Neuregistrierungen).

viele Grüße

Die zweite Variante ist bei uns technisch nicht umsetzbar. Die erste Variante müssen wir mal analysieren.

[Mamusis]

keine sorge, werd dir heute am frühen abend dazu antworten bzw. erklären wie das bei uns funktioniert....beitrag wird dann editiert von mir....nicht mit R/3 ??? hmm, ok.....die grundfunktionalitäten müssten aber trotzdem die gleichen sein, oder ? also die systemlogik als solches meine ich.

[elf4]

Zitat von Mamusis

keine sorge, werd dir heute am frühen abend dazu antworten bzw. erklären wie das bei uns funktioniert....beitrag wird dann editiert von mir....nicht mit R/3 ??? hmm, ok.....die grundfunktionalitäten müssten aber trotzdem die gleichen sein, oder ? also die systemlogik als solches meine ich.

Leider nicht unsere Buchhalterin die selbst R/3 Erfahrungen hat meinte das beide Systeme verschieden sind und unsers im Vergleich zu R/3 stark abgespeckt ist. Dennoch interessiert mich der Ablauf.