Wir haben immer wieder das Problem, dass Kunden sich mehrfach registrieren. Das gibt dann ein ziemliches Durcheinander i.V.m. der Anbindung an die Warenwirtschaft. Kennt jemand einen Trick, die erkannten Dubletten in vernünftiger Art und Weise zusammenzuführen?

Hallo Thomas

Kämpfen seit Jahren mit demselben Problem. Bis jetzt haben wir das alles in Handarbeit gemacht:
- Überprüfung ob Kunde bereits existiert.
- Übernahme der Mutationen von neuer auf alte Adresse.
- Auswahl der bestehenden Kundenadresse für den neuen Auftrag.
- Kontrolle der doppelten Adresse, ob kein Auftrag mehr verknüpft ist.
- Löschen der doppelten Adresse
- Zurücksetzen des Adresszählers
- Exportieren der Daten.

Natürlich bestünde die Möglichkeit, die Mutationen über einen SQL Befehl zu vereinfachen und so die Adressen zusammen zu führen. Wir wollen aber die Kontrolle über die Mutation behalten und nicht z.B. nachträglich erfasste Telefonnummern wieder verlieren.

Den im WBS bestehenden eMail Vergleich zur Verhinderung der Dubletten mussten wir rausnehmen, da sonst eine Anmeldung nicht mehr möglich ist, wenn jemand bereits mit seiner eMail auf Grund einer Anfrage in den Kontakten verzeichnet ist.

Ich wäre schon an einem Mini-Projekt zur Dublettenüberprüfung interessiert. Ich will aber nicht immer alles alleine machen.

Meine Vorstellung geht dahin, eine dezidiertere Überprüfung zu machen und den Kunden während der Erfassung darauf hinzuweisen, dass er eventuell bereits registriert ist bzw. einen Login zur Verwendung seiner bestehenden Angaben vorschlagen.

Wenn das einmal erstellt wurde ist es einfach dem Kunden auch mitzuteilen, dass er die Lieferadresse nicht einzugeben braucht, wenn sie eine Dublette der Rechnungsadresse darstellt. Ich habe viele Kunden die, trotz deutlichem Hinweis "Lieferadresse falls abweichend" immer noch die Lieferadresse mit ausfüllen.

Leider kann man, so wie es aussieht, auch keinen Input zum WBS 4.0 liefern. Somit weiss man nicht, ob man "auf Halde" programmiert. An einer Zusammenarbeit von WBS Usern zur Verbesserung der Funktionalitäten wäre ich schon interessiert. Ich möchte aber auch mal copy/paste machen können und nicht nur Code liefern müssen.

Gruss
Peter

Hallo Peter,

die Email scheidet auch bei uns als eindeutige Identifizierung aus, einerseits wegen den Kontakten, andererseits bei mehreren Familienmitgliedern, die rechtlich getrennte Personen sind, sich aber dieselbe Email Adresse teilen.

In der Wawi klappt die Prüfung inzwischen erstklassig, aber die Rückübertragung bekomme ich nicht hin, wenn mehrere Adressdatensätze vorhanden sind. Die Zusammenführung mehrerer Adresssätze muß von WBS vorgesehen sein. Ein Problem ist allerdings insoweit die Datenstruktur, als die Adressdatensätze sowohl als Stammdaten als auch als Adresse für die Belege dienen. Nach einer Anpassung der Adressen werden daher auch bestehende Aufträge de facto geändert.

Ich gebe zu, dass die Problematik nicht einfach ist, aber bei mehr als 50.000 Kunden wird das irgendwann einfach zum Problem, weil nicht jeder Kunde von Hand geprüft werden kann. Vielleicht kann WBS vorsehen, dass bestimmte Adressdatensätze einer anderen Kundennummer zugeordnet sind. Die Adresse als solche kann dann bleiben, hat aber keinen eigenen Login und keine eigenen Kontakte oder Belege.

Grüße
Thomas

Hallo @all,

zunächst: es gibt im kommenden System eine Dublettenprüfung mit der Option Adressen zusammenzulegen.

Was uns hier noch ein wenig Kopfzerbrechen bereitet, wie wir bei der Datenübernahme von Adressen aus einem WBS 3.x Projekt verfahren sollen.

Die bisherige Überlegung ist einerseits die eMail Adresse und dann die Adressdaten als Kriterium festzulegen und dann jeweils alle Bewegungsdaten auf die zuletzt geänderte/angelegte Adresse zusammenzuführen.

Die eMail Adresse sollte - anders als Thomas hier meint - unseres Erachtens durchaus eindeutig sein. Auch bei Familienmitgliedern sollte die Forderung nach einer eindeutigen Mailadresse kein besonderes Hindernis darstellen, zumal diese ja oft in Verbindung mit einem Kennwort als Login benutzt wird.

Wenn diese nicht mehr eindeutig wäre, beginnt das Problem schon bei der "Kennwort vergessen" Funktion und der Generierung und Zusendung eines neuen Kennworts.

Es ist auch dann nicht mehr so, dass eine Kontaktanfrage die eMail Adresse im Bestellprozess blockiert. Hier führen wir künftig die Adresse mit dem vorhandenen Datensatz zusammen, solange kein "wirkliches" Kundenkonto exisitert. Dann gibt es nur noch eine Sperre wenn tatsächlich bereits ein Kundendatensatz existiert.

Die Dublettenprüfung findet dann in einer separaten Funktion statt, bei man die Zusammenlegung steuern kann. Hier werden Übereinstimmungen bei den Adressdaten geprüft, somit kann auch eine anderslautende eMail Adresse zumursprünglichen Kunden führen.

Beste Grüße
Alexander Schreiner

Hall Herr Schreiner

Ich kann für die Datenübernahme 3.x -> 4.x keinen dieser Wege empfehlen.

Ich würde nicht zuviel auf einmal wollen und wäre schon froh, wenn die Datenübernahme 1:1 funktioniert.
Adressen löschen bzw. zusammenführen, ändern oder was auch immer gehört auf jeden Fall in einen zweiten Schritt, entweder per SQL Makro oder noch besser als Menüoption.

Eine Dublettenprüfung bedeutet, was ihr Name auch sagt - eben prüfen. Damit ist nicht das Löschen oder Zusammenführen von Adress und Auftragsdatensätzen gemeint. Der User sollte immer noch Verfügungsgewalt darüber haben, was nun eigentlich wohin kopiert, zusammengeführt oder gelöscht wird.

Anders verhält es sich mit der Elimination von Datenleichen. Hier wäre ein Makro wünschenswert, welches die Datenbank auf nicht existente Verknüpfungen prüft (items ->itemnodes, itemprices / users -> usernodes / sales -> salenodes, salepos usw.). Damit würden auch eventuelle Abfragefehler beim Arbeiten im WBS ausgeschlossen.

Betreffend Eindeutigkeit der eMail Adresse:
Wer Firmenkunden hat und über eine WaWi verfügt, wird diese nicht als mehrfache Adressdatensätze anlegen wollen, da sie in der WaWi wieder zusammengeführt werden. Dort existieren nämlich bereits die Untermengen Lieferadresse und Ansprechpartner in eigenen Dateien der Datenbank. Dort sind die Angaben zu Namen, Adresse, Telefon usw. verzeichnet.

Die alternative Rechnungsadresse in WBS konnte ich noch nie verwenden. Die Stammdaten enthalten bereits die Rechnungsadressdaten und die alternative Lieferadresse eine allfällig unterschiedliche Lieferadresse.

Wenn schon die Idee einer Menge von gleichlautenden Adressätzen mit unterschiedlichen Logins bestünde, könnte dies:
- entweder über eMail/Login in der Ansprechpartner Untermenge oder
- über eine Menge Adressdatensätze, welche mit einem Verweis auf eine gemeinsame Adresse für Rechnungsstellung gelöst werden. Das würde nur ein zusätzliches Datenfeld in den "weiteren Daten" erfordern.

Mit dem Login der Adresse für Rechungsstellung sieht der Kunde (Kundenbuchhaltung?) alle Aufträge/Bestellungen/Rechnungen, welche bereits getätigt wurden und der jeweilige Ansprechpartner verfügt mit seinem Login nur über die Ansicht seiner Bestellungen/Rechnungen.

Noch etwas: da wir heute durchaus ein wenig verschwenderischer mit unseren Daten umgehen können fordere ich von WBS 4.x dass die Adressdaten in der Datei Sales mit abgespeichert werden. Es kann nicht sein, dass bei einer Adressänderung auch alle alten Rechnungen/Lieferungen plötzlich auf die neue Adresse lauten.

Ebenso möchte ich nicht, dass die Datensätze beim Wechsel von Auftrag zu Lieferschein zu Rechnung einfach nur gewandelt werden.
Es müssen hier genau so jeweils neue Datensätze in Sales und Salepos angelegt werden. Es kommt immer wieder mal vor, dass sich während eines Bestellprozesses Preise oder andere Angaben ändern. Diese Änderungen müssen, will man eine gewisse Kongruenz zur WaWi herstellen, auch jederzeit nachvollzogen werden können.

Gruss
Peter

Das entscheiden üblicherweise immer noch die Kunden. Wenn Willi oder Lisa Müller bestellen, bleibt es noch immer ein Unterschied, auch wenn beide dieselbe E-Mail Adresse nutzen.



Das halte ich auch vor dem Gesichtspunkt der Beweisbarkeit von Bestellungen für äußerst sinnvoll. Dann könnten Stammsätze viel leichter Zusammengefaßt werden.

Grüße
Thomas