Kundendaten in alten Bestellungen...

[Bernhard]

Hallo,

ich bin mir sicher, dass ich dazu schonmal etwas gelesen habe, finde es aber nicht wieder:

wenn ein Kunde, der schon mehrfach bestellt hat, sich bei seiner aktuellen Bestellung beim Eingeben der Kundendaten vertippt (oder wenn er z.B. umgezogen ist etc.), dann werden alle in der Bestellverwaltung gespeicherten Daten der früheren Bestellungen überschrieben, solange er die selbe E-Mail-Adresse verwendet.

Einzig das Land bleibt.

Wie lässt sich das verhindern?
Ich vermute mal, dass ich da eine Option in der Konfiguration übersehen habe?

Der Abgleich der Kundendaten mit älteren Bestellungen erscheint mir sinnvoll.
Aber das automatische Überschreiben geht mal gar nicht.
Sinnvoll wäre m.E. eine Meldung „neuer Vorname“ oder „Hausnummer geändert“ etc. (gerne deutlich hervorgehoben).

Ich freu mich auf hilfreiche Antworten!

Grüße
Bernhard

[maennchen1.de]

Hallo!

wenn ein Kunde, der schon mehrfach bestellt hat, sich bei seiner aktuellen Bestellung beim Eingeben der Kundendaten vertippt (oder wenn er z.B. umgezogen ist etc.), dann werden alle in der Bestellverwaltung gespeicherten Daten der früheren Bestellungen überschrieben, solange er die selbe E-Mail-Adresse verwendet.

Derzeit ist das die Funktionweise von wpShopGermany.

[Bernhard]

Hallo Roger,

Hallo!

wenn ein Kunde, der schon mehrfach bestellt hat, sich bei seiner aktuellen Bestellung beim Eingeben der Kundendaten vertippt (oder wenn er z.B. umgezogen ist etc.), dann werden alle in der Bestellverwaltung gespeicherten Daten der früheren Bestellungen überschrieben, solange er die selbe E-Mail-Adresse verwendet.

Derzeit ist das die Funktionweise von wpShopGermany.

Danke für Deine Antwort.

Da ich damit nicht glücklich bin: wie lässt sich das abstellen?
Falls es sich nicht abstellen lässt: was kostet es, eine entsprechende Änderung durch Euch vornehmen zu lassen?
Das Problem ist erst mit Version 3.x aufgetreten, ältere Versionen haben diesbezüglich keine Probleme gemacht.

Grüße
Bernhard

[maennchen1.de]

Da verwechselst du evtl. etwas. Diese Funktion besteht IMHO seit Version 1.0 und wurde bisher nicht verändert.
Gern erstellen wir dir ein Angebot. Bitte stelle deine Anfrage unter: http://shop.maennchen1.de/kontaktformular/
Beschreibe bitte dort, was genau mit der Adresse, den Daten o.ä. passieren soll. Gib ggf. auch ein Budget an.
Konkretisiere deine Anfrage auch hinsichtlich deiner Einstellungen in der Kundenverwaltung. Ein Screenshot dürfte sicherlich einiges leichter machen, deine Konfiguration für den Angebostersteller zu erfassen.

[Bernhard]

Hallo Roger,

Diese Funktion besteht IMHO seit Version 1.0 und wurde bisher nicht verändert.

In den 2.5.x-Versionen gab es diesen Bug noch nicht.

Grüße
Bernhard

[maennchen1.de]

Ich habe mich soeben rückversichert. Diese Funktionsweise ist seit Anbeginn der Software so umgesetzt und hat sich seither nicht geändert.

[solala]

Hallo Roger,

Diese Funktion besteht IMHO seit Version 1.0 und wurde bisher nicht verändert.

In den 2.5.x-Versionen gab es diesen Bug noch nicht.

Grüße
Bernhard

Hallo,

ich habe gerade in meiner 2.5.8er Version nachgesehen. Da ist es genau so wie Roger sagt. Als Referenz wird die Kunden-ID benutzt. Lediglich die Lieferadresse ist im Datensatz der "order-Tabelle" drin.

[Bernhard]

ich bin mir sicher, dass ich dazu schonmal etwas gelesen habe, finde es aber nicht wieder...

Hab heute lange gesucht und zumindest einen Thread zu diesem Bug gefunden.

Vor eineinhalb Jahren war die Aussage:

Es stimmt, es ist keine saubere Lösung, wenn sich nachträglich Bestelldaten ändern.

So bin ich erstmal bei 2.5.8 geblieben, davon ausgehend, dass der Bug gefixed würde...

Hallo Roger,

Diese Funktion besteht IMHO seit Version 1.0 und wurde bisher nicht verändert.

In den 2.5.x-Versionen gab es diesen Bug noch nicht.

Hallo,

ich habe gerade in meiner 2.5.8er Version nachgesehen. Da ist es genau so wie Roger sagt. Als Referenz wird die Kunden-ID benutzt. Lediglich die Lieferadresse ist im Datensatz der "order-Tabelle" drin.

Hallo Solala,

ich habe das Plugin ausgiebig getestet, bevor ich es vor ca. zwei Jahren gekauft habe.
Die erste Version, die ich damals heruntergeladen hatte, war 2.3.1.
Bis heute habe ich 2.5.8 im produktiven Einsatz und hab dort jetzt nochmal intensiv in die Bestellverwaltung geschaut.
Viele Kunden haben bei Folgebestellungen veränderte Daten eingegeben, aber bei keinem einzigen wurden dadurch nachträglich ältere Bestelldaten überschrieben.
Wäre dieser Fehler jemals aufgefallen, hätte ich das Plugin sicher nicht gekauft; bzw., wäre er erst nach dem Kauf aufgefallen, hätte ich ihn natürlich sofort mitgeteilt, im Glauben, dass er dann abgestellt würde.

Es mag natürlich sein, dass sowohl meine lokalen Testinstallationen als auch die im produktiven Einsatz fehlerhaft waren, mit einem Fehler, der sich nirgends bemerkbar gemacht hat, außer eben, dass er diesen Bug unbemerkbar gemacht hat.
Das nutzt mir jetzt aber leider exakt überhaupt nichts: ich habe ein komplett neues Theme für den Shop fertig, dieses selbstverständlich auf die aktuellste Version des Plugins abgestimmt und kann nun den dem Kunden zugesagten Termin zur Veröffentlichung nicht halten, da das Entwicklerteam keinen Handlungsbedarf sieht.

So kann ich mir jetzt überlegen, was ich mache - und, wie ich es dem Kunden erkläre.

Grüße
Bernhard

[maennchen1.de]

Hab heute lange gesucht und zumindest einen Thread zu diesem Bug gefunden.

Auch wenn es aus deiner Sicht nicht die Funktion erfüllt, die du dir wünschst, so ist es noch lange kein Fehler (Bug).
Im selben Thread wurde von uns sogar ein Workaround erklärt, welcher das Problem im gewissen Maße einschränkt.

[solala]

Dieser Effekt kann ja nur auftreten, wenn Du das Kundenlogin aktiviert hast. Ich habe es nicht.
Bei nicht aktiviertem Kundenlogin muss der Kunde jeweils seine Adresse neu eingeben und es wird dann bei der Bestellung eine neue Kundennummer vergeben.
Somit kann der Kunde seine Adresse auch im Nachhinein nicht ändern.

Als Lösung bei aktivem Kundenlogin schlage ich für die 2.5.8er folgendes vor:
1) Erweiterung der Tabelle "...order" um die Spalten: "invoice_vname", "invoice_name", "invoice_strasse", "invoice_hausnr", "invoice_plz", "invoice_ort" und "invoice_land".
2) Bei Abschluss der Bestellung werden dann die Rechnungsdaten in die o.g. Spalten geschrieben.
3) Anpassung der "user_views/Order/view.phtml" in der Ansicht der Bestellung im Backend: Die Rechnungsadresse wird nicht von der Kunden-ID, sondern von der Order-ID gezogen.

Da bei einer späteren Adressänderung des Kunden die Rechnungen vorheriger Bestellungen normalerweise schon geschrieben wurden und auch die Bestellbestätigungen rausgehen bevor der Kunde seine Adresse ändert, sollten eigentlich keine weiteren Änderungen nötig sein.

Bernhard, den Arbeitsaufwand hierfür schätze ich für die 2.5.8er bei meinen "solala"-Programmierkenntnissen auf 2-3 Stunden (siehe meine Signatur).

Eigentlich sollten die von mir beschriebenen Änderungen (angepasst an den aktuellen "Sprachgebrauch") auch bei der 3.4er Version funktionieren.

Wer auch immer das umsetzt, den bitte ich, die Änderungen hier zu veröffentlichen, dann haben wir alle was davon. So soll es sein.

[Bernhard]

Hallo Solala,

2.5.8

Dieser Effekt kann ja nur auftreten, wenn Du das Kundenlogin aktiviert hast. Ich habe es nicht.
Bei nicht aktiviertem Kundenlogin muss der Kunde jeweils seine Adresse neu eingeben und es wird dann bei der Bestellung eine neue Kundennummer vergeben.
Somit kann der Kunde seine Adresse auch im Nachhinein nicht ändern.

Jetzt kommt zumindest schonmal etwas Licht ins Dunkel:
Du sprichst von 2.5.8, ich spreche von 3.3.9, bzw. genau genommen vom Update von 2.5.8 auf 3.3.9:

In der Version 2.5.8 wird der nicht eingeloggte Kunde bei jeder Bestellung neu angelegt, die Kundendaten in alten Bestellungen werden nicht überschrieben.
In 3.3.9 wird der nicht eingeloggte Kunde bei einer erneuten Bestellung anhand der E-Mail-Adresse wiedererkannt und die Kundendaten in alten Bestellungen werden überschrieben.

Ein konkretes Beispiel habe ich auch, das real vorkommt, und das zeigt, warum die Kundendaten nicht überschrieben werden dürfen:
Eine Kundin bestellt für sich, gibt dazu die korrekten Daten an.
Zehn Minuten später bestellt sie erneut, mit der gleichen E-Mail-Adresse aber mit anderen Daten und schreibt in den Bestellkommentar „Bestellung für eine gute Bekannte, die kein Internet hat, mfG A.B.“, d.h. gezeichnet nur mit den Initialen, davon ausgehend, dass sie ja aufgrund der vorangegangenen Bestellungen eh bekannt ist.

Nur ist sie nun nicht mehr bekannt, da in allen vorangegangenen Bestellungen nun Name und Adresse ihrer Bekannten steht.

Ich weiß immer noch nicht, wie ich meinem Kunden erklären soll, dass das „noch lange kein Fehler“ ist...

Grüße
Bernhard

[solala]

So langsam "kommen wir zusammen"
Ich dachte Du hättest auch die 2.5.8er im Einsatz.

Dass in der 3er Version ein Kunde anhand der E-Mail erkannt wird, ist natürlich ein Feature.
Dass dann die Adresse mit einer neuen Adresse überschrieben wird, ist auch ein Feature. Aber nicht unbedingt ein gewolltes...

Die schnelle Lösung wäre einfach das erst genannte Feature abzuschalten. Aber updatesicher wird das wohl kaum gehen, da sich hier sicherlich eine Core-Funktion verbirgt.
Auf der sicheren Seite ist man tatsächlich nur, wenn auch die Rechnungsadresse im Bestell-Datensatz gespeichert wird. Wäre ich ein Finanzamt, würde ich auf so was bestehen.

[Bernhard]

Hallo Solala,

So langsam "kommen wir zusammen"
Ich dachte Du hättest auch die 2.5.8er im Einsatz.

noch hab ich 2.5.8 im Einsatz.
Wenn ich jetzt aber alles neu mache, dann hatte ich es für sinnvoll gehalten, auch auf die aktuellste Version des Plugins zu gehen.
Da hab ich die Rechnung ohne die Entwickler des Plugins gemacht, die es offensichtlich für besser halten, bei 2.5.8 zu bleiben.

Dass in der 3er Version ein Kunde anhand der E-Mail erkannt wird, ist natürlich ein Feature.
Dass dann die Adresse mit einer neuen Adresse überschrieben wird, ist auch ein Feature. Aber nicht unbedingt ein gewolltes...

Du kannst es in diesem Thread nachlesen: „Diese Funktionsweise ist seit Anbeginn der Software so umgesetzt und hat sich seither nicht geändert“
Das heißt: die Kundendaten wurden schon immer überschrieben - wir waren nur zu dumm, das zu bemerken.

Mal ganz ehrlich, liebes wpShopGermany-Team: für wie blöd haltet Ihr Eure Kunden eigentlich?

Auf der sicheren Seite ist man tatsächlich nur, wenn auch die Rechnungsadresse im Bestell-Datensatz gespeichert wird. Wäre ich ein Finanzamt, würde ich auf so was bestehen.

Ich muss gestehen, dass ich bisher nur an meinen Kunden gedacht hatte, und erst jetzt, wo Du es sagst, ans Finanzamt denke...
...aber wir haben hier in diesem Thread ja erfahren, dass wir auch dem Finanzamt völlig problemlos erklären können, dass das „noch lange kein Fehler“ ist.

Wenn der Support so bleibt, bleibt mir nichts anderes, als alles auf 2.5.8 neu zu schreiben, da die aktuelle Version von wpShopGermany so nicht für den produktiven Einsatz geeignet ist.
Damit ergibt sich die m.E. interessante Frage, wer die Kosten für den entstehenden Aufwand trägt...

frustrierte Grüße
Bernhard

[solala]

Du kannst es in diesem Thread nachlesen: „Diese Funktionsweise ist seit Anbeginn der Software so umgesetzt und hat sich seither nicht geändert“
Das heißt: die Kundendaten wurden schon immer überschrieben - wir waren nur zu dumm, das zu bemerken.

Wie geschrieben hatte ich bis jetzt noch nie das Kundenlogin im Einsatz. Hätte ich es benutzt, wäre es mir auch (wie Dir) irgendwann aufgefallen und ich hätte im Forum einen entsprechenden Hinweis hinterlassen.

Mal ganz ehrlich, liebes wpShopGermany-Team: für wie blöd haltet Ihr Eure Kunden eigentlich?

So hart würde ich es nicht ausdrücken. Ich kenne sehr wohl die Situation, wenn Software von zweifelsfrei fähigen Entwicklern geschrieben wird, die selber jedoch nicht 100% im Anwender"modus" stehen (können). Auf eine Shopsoftware bezogen: 100%ige Entwickler sind keine 100%igen Verkaufsprofis und 100%ige Verkaufsprofis sind keine 100%igen Entwickler. Müssen sie auch nicht sein. Können sie auch nicht sein. Ich lehne mich jetzt mal weiiit aus dem Fenster und behaupte, dass sogar viele Internetshopbetreiber keine 100%igen Verkaufsprofis sind. Ich auch nicht, arbeite mich aber nach >10 Jahren Vertrieb langsam ran .Und programmieren...
... bei mir steht's sogar in der Signatur.

Lange Rede kurzer Sinn, jede Entwicklungsorganisation ist auf die Mithilfe/Inputs der Nutzer angewiesen.
Der Schritt von 2.5.8 auf 3.4.1 ist auf alle Fälle ein richtiger Sprung in die richtige Richtung, sie haben in der 3er Version viele Nutzerhinweise mit einfließen lassen .

Jetzt wurde das M1-Team auf einen weiteren, vertriebstechnisch sicherlich äusserst wichtigen Punkt hingwiesen. Nämlich die Datenkonsistenz von bereits getätigten Verkäufen. So ist es zumindest für mich ein Muss, dass im Datensatz der Bestellung auch die Rechnungsadresse mit drin steht (eine davon abweichende Lieferadresse steht ja schon drin). Das gehört einfach zusammen, so wie <möge sich der Leser selbst was ausdenken>.
Ich bin mir sicher, dass sich das M1-Team bald um diesen Umstand kümmert, nachdem wir uns jetzt alle (hier mitlesenden) dessen bewusst geworden sind.

Trotz allem meines Verständnisses für die Situation ist jedoch eins sicher: Ich würde mir keine Shopsoftware kaufen, von der ich vorher wüsste, dass es eine solche Dateninkonsistenz gibt. Da hätte ich zu viel "Schiss" vor dem Finanzamt.

Und jetzt haben wir uns alle wieder lieb, gelle?

[maennchen1.de]

Das Thema mit dem Finanzamt möchte ich gern ausräumen:
Grundlegend zählt hier das erstellte Rechnungsdokument mit dessen ausgewiesenen Steuern, nicht die Bestellung an sich. Das Rechnungs-PDF wird vom Shop (sofern das Rechnungsmodul im Einsatz ist) unveränderlich gespeichert.

Zum speichern der Adressen kann ich bisher keinen Eintrag in der Feature Wunschliste sehen (außer dieses). Auch wenn es jetzt bei einem Kunden dringend ist, so stehen die Wünsche der Masse der wpShopGermany Nutzer im Vordergrund. Drohungen oder Persönlichkeiten sind wirkungslos und unprofessionell.
siehe: Wann ist Feature XY umgesetzt?