Neu Kundendubletten (automatisch) zusammenführen

[GG_International]

Hallo zusammen,

wir haben aktuell folgendes Problem:
Wir haben über 135.000 Kundensätze in der Wawi, von denen mindestens 19.000 Datensätze Dubletten sind (geprüft via Ameisenexport-Kundendaten -> Excel -> Dublikate entfernen (auf Spalte EMail bezogen) -> ca. 19.000 Einträge gelöscht) und würden die Dubletten gerne zusammenführen.
Es gibt zwar diese praktische Zusammenführen-Funktion, allerdings können da immer nur 2 Kunden zusammengefasst werden und auch nur manuell (nicht etwa durch eine Workflow-Aktion).

Daher die Frage, ob jemand eine Idee hat, wie man diesen Berg an Dubletten (idealerweise automatisiert) zusammenführen kann? Eventuell auch direkt in der Datenbank?
(an evtl. mitlesende Servicepartner: Gerne auch Vorschläge die Geld kosten, Hauptsache wir bekommen das Problem gelöst)


Hintergrund wie es dazu kommen konnte:
Wir nutzen den xml-Auftragsimport der Wawi um die Aufträge aus unserem vollkommen separat gepflegten Prestashop 1.6 zu importieren. (ich weiß gibt nen Connector, aber der lässt sich meines Wissens nicht nachträglich einziehen bzw. uns ist das auch zu heiß, das auszuprobieren) Anschließend erfolgt die gesamte Abwicklung der Aufträge über JTL (Wawi, WMS, Shipping). Den xml-Export aus Presta haben wir uns programmieren lassen.

 

[Baby Sweets]

Gab es hierzu ggf. Lösungsvorschläge? Wir stehen vor dem gleichen Problem!

 

[wawi-dl]

https://forum.jtl-software.de/threa...n-funktioniert-nicht.87441/page-2#post-518160

 

[wawi-dl]

Wir holfen mal das Thema hoch, wir lassen uns eine Email senden, wenn eine Dublette erkannt wird.

Wir prüfen mit ODER diese 2 Bedingungen unter Workflows "Kunde -> Angelegt":

Emailadresse identisch

{% capture query %}
SELECT COUNT(*) FROM tKunde WHERE cEMail='{{ Vorgang.EMail }}'
{% endcapture -%}
{{ query | DirectQueryScalar }}

eBayusername identisch

{% capture query %}
SELECT COUNT(*) FROM tKunde WHERE cEbayName='{{ Vorgang.eBayName }}'
{% endcapture -%}
{{ query | DirectQueryScalar }}

Wenn eines von beiden größer 1 ist, EMAIL an uns um den Kundenstamm zusammenzuführen.


@Rico Giesler
Ich hoffe es tut sich hier etwas, wir haben am Tag locker 10 Dubletten!

Bei 150.000 Kundenstämme haben wir über 8.000 Dubletten, die auch bis zu 42x identisch sind, insgesamt fast 12.000 Datensätze.
Wir reden hier also von fast 10% Dubletten!!!!!!!!!!!!

 

[Rico Giesler]

Lasst das am besten direkt über den Support prüfen und klären.
Die können euch da mit Sicherheit mehr Auskunft geben.

 

[wawi-dl]

Danke @Rico Giesler, das Problem ist doch seit vielen Jahren bekannt

Da brauchen wir nicht den Support belästigen, man wollte das doch angehen.

!!!!! Bitte alle das Ticket voten !!!!! WAWI-33888
https://issues.jtl-software.de/issues/WAWI-33888

@Rico Giesler , selbst wenn ich nur ein doppeltes Leerzeichen lösche, der Kunde neu bestellt, wird sofort ein neuer Kundenstamm angelegt

 

[wawi-dl]

Das Voting ist wirklich mager, VIELE ärgern sich, VIELE können mit Dubletten nicht arbeiten *kopfkratz* ... nochmals Voting-Weckruf!

Wir haben jetzt in 2 Wochen 291 Dupletten gehabt


!!!!! Bitte alle das Ticket voten !!!!! WAWI-33888
https://issues.jtl-software.de/issues/WAWI-33888

 

[itratosTeam]

Hallo @all,

Wir haben jetzt eine Software entwickelt die die Kundenaccounts zusammenlegt, so als wenn man es über das JTL Backend macht - wir automatisierten dies aber.

Für unsere Entwicklung erhielten wir versch. JTL Datenbanken von unseren Kunden mit 500 - 2000 Kunden die mind. 2 bis 15 Kundenkonten in JTL erzeugt haben.
Über das Backend von JTL kann man evtl. 20 Kunden manuell fixen, aber wenn es ein paar hundert sind ist das nicht mehr möglich

Unsere Software prüft alle Kundenkonten und migriert zu dem mit der letzten Bestellung, läuft wunderbar und könnte zuerst in einer DEV Umgebung (Kopie der Live) getestet werden. Die software erzeugt zuerst eine CSV mit allen Datensätzen die zu migrieren sind
Bei 500 Kundenkonten hat unsere Software ca. eine Stunde zu tun, auf normaler Hardware, dies würde manuell in JTL ein paar Wochen in Anspruch nehmen.

 

[wawi-dl]

Hi Timo,

liest sich sehr gut, danke für die Info, wir haben aktuell noch 7.000 alte Dubletten im System.
Wir lassen uns aktuell mit diversen Regelprüfungen bei einer neuen Kundenanlage sofort eine Email zusenden,
damit ein Kollege diese dann prüfen und zusammenfassen kann (pro Tag 10-20 Stück, in 1-2min erledigt mit MouseRecorder).

Ich möchte deine Arbeit nicht schlecht machen, ich würde diese Software aber wohl niemals einsetzen wollen, dafür gibt es viele Gründe!
Du darfst gerne mal Stellung dazu nehmen oder dich mal per PN melden.

1.) Die JTL-Datenbank wird sich mit 1.6 erheblich ändern, es gibt so viele Abhängigkeiten in anderen Tabellen, ist daher alles höchst gefährlich in Bezug auf Updates. Wie wird das sichergestellt?

2.) Ist das eine komplette eigene Entwicklung und Logik? Warum wird hier kein JTL-StoredProcedure verwendet "spKundenZusammenfuehren"?

3.) Wie soll die Software wissen, welche Kundenstämme zusammengefasst werden können und welche nicht?

• Dublette entstanden durch neue Emailadresse (z.B. eBay, vor allem JETZT mit anonymisierten Emailadressen) --> JTL hat auf unseren Wunsch ein Projekt dazu gestartet, dies auf User-ID zu ändern!
• Dublette entstanden durch minimale Änderung der Adresse (z.B. Straße Leerzeichen dazu/weg oder Adresszusatz geändert, PLZ geändert)
• Dublette entstanden durch Änderung der Person, Emailadresse oder eBay-Benutzername noch identisch. Was soll genommen werden? Was ist mit Historie? --> JTL hat auf unseren Wunsch ein Projekt dazu gestartet, damit man auch eine Historie evtl. hat.
• Dubletten die durch mehrere Ansprechpartner von Firmen entstehen, Emailadresse aber identisch ist. Was wird hier also definiert?

4.) Wie sieht es mit Änderung der Kundennummer in Aufträgen es, die noch nicht abgeschlossen sind? --> JTL hat hier ebenfalls ein Ticket offen.

5.) Was passiert mit Debitoren? Kenne mich damit zu wenig aus, aber hier werden ja auch diverse Sachen zusammen verbucht, wenn man Debitoren (Kundenstämme) zusammenfasst, ändern sich ja auch die "Summen"?!

... gibt noch paar andere Punkte, das ist leider leider nicht so einfach zu lösen.

Ich greife daher dann wohl lediglich auf SPs von JTL zurück, da mir das Thema zu heiß wäre.

 

[itratosTeam]

Hallo Wawi-DL,

danke für Deine Zusammenfassung, aber genau das machen wir doch, wir automatisieren das was JTL als SP's bereits anbietet.
Ich habe mir hier ganz sicher nicht etwas eigenes einfallen lassen, was von den strukturellen Vorgaben abweicht, würde ja kein Sinn machen.

Egal was Du in der Kundenmaske siehst, am Ende ist es der Inhalt des letzten Accounts.
Wir haben bei sehr umfangreichen Kunden den vorherigen Zustand erfasst und die Daten im Detail im letzten Account geprüft, jeder Vorgang ist vorhanden und auch die Summen der Umsätze stimmen.

Ich möchte Dir hier ganz offiziell anbieten das wir Dir die 7000 Dubletten kostenlos in einer DEV Umgebung auf Deinem Server migrieren und Du kannst dann gerne wieder hier Deine Erfahrung schildern, die uns dann hilft oder oder uns zerschmettert

 

[wawi-dl]

Danke, dann wäre ja ein Punkt beantwortet, ging leider in dem Post nicht hervor.

... Egal was Du in der Kundenmaske siehst, am Ende ist es der Inhalt des letzten Accounts. ...

OK, diese Entscheidung ist aber zu simpel, dann würden hier bereits alle alten Emailadressen durch anonymisierte Emailadressen ersetzt werden, ein NoGo.
--> aktuell das Hauptproblem bei Bestandskunden, JTL muss daher hier zuerst die Logik auf Benutzer-ID ändern.

... Wir haben bei sehr umfangreichen Kunden den vorherigen Zustand erfasst und die Daten im Detail im letzten Account geprüft, jeder Vorgang ist vorhanden und auch die Summen der Umsätze stimmen. ...

Kannst du das genauer erläutern? Welche Summen wurden?
Mir geht es um Debitoren, 2 identische Kundenstämme = 2 Debitoren = 2 Konten beim Steuerberater.
Auch der Steuerberater muss doch dann die Info erhalten, dass Debitoren X+Y zusammengelegt wurden???
Bin darin leider nicht firm genug, aber die Arbeit hätte doch dann auch der StB im Nachgang?

... Ich möchte Dir hier ganz offiziell anbieten das wir Dir die 7000 Dubletten kostenlos in einer DEV Umgebung auf Deinem Server migrieren und Du kannst dann gerne wieder hier Deine Erfahrung schildern, die uns dann hilft oder oder uns zerschmettert ...

Ich habe bis dato zu wenig Infos zum Tool, bislang konnte ich auch keine Screenshots finden.

Aktuell weis ich nicht mal, wie ihr überhaupt Dubletten indentifiziert, ich kann dir bereits mindestens 3 Varianten nennen ... wer entscheidet dann welche Variante greift bzw. welche gültig ist?
Das kann in meinen Augen keine Software!
1.) verschiedene Emailadresse, Adresse aber identisch
2.) Emailadressen identisch, Adressen aber minimal abweichend ("Musterstr. 11" vs. "Muster Str. 11")
3.) Firmenbezeichnung identisch, Anprechpartner/Besteller immer abweichend
4.) Firmenbezeichnung identisch, aber Bezeichnung einmal in Firma, einmal in Vorname+Nachname verteilt
5.) eBay-Benutzername identisch, EMailadresse abweichend
6.) eBay-Benutzername identisch, Kontoinhaber geändert
7.) eBay-Benutzername identisch, Adresse geändert
8.) identische Adressen, Bestellung aber über Shop und eBay (--> spätestens hier scheitert die Software komplett, da JTL aktuell eBay-Benutzername löscht beim Zusammenfassen)
... gibt noch einige andere Sonderfälle, du KANNST es also NICHT per Software blind lösen, hier muss jemand Entscheidungen treffen.

Man muss hier 2 Stufen fahren, dass z.B. nur zu 100% Übereinstimmung verarbeitet werden, dann bleibt ein großes Delta offen?!

Aus diesem Grund bleibt bei uns der Bestand wie er ist, wir fangen es per Workflows ab und warten auf Anpassungen in der JTL Logik.

 

[itratosTeam]

Hallo Wawi-DL,

aktuell arbeiten wir die Daten ab und prüfen nach eMail Dubletten, den das ist ein Unique Wert auf dem man sich verlassen kann.

Eine Frage habe ich aber, wenn bei Dir ein Kunde 10x ohne Registrierung bestellt hat und so 10 Konten in JTL erzeugt, führt dann Dein Steuerberater zu jedem Konto des Kunden in JTL ein Debitoren Konto? Wenn das so wäre dann würde beim Steuerberater doch einiges schief laufen.

Wenn man den gleichen Kunden zum letzten Account migriert über den er die letzte Bestellung tätigte, dann hat man sichergestellt das man den aktuellsten Account verwendet.
Ich teilte Dir pauschal mit das wir alles übernehmen was Du in der Kundenansicht sehen kannst, dazu zählen Bestellung, die Artikel der Bestellungen, die Retouren die Stornos usw. einfach alles was du dort sehen kannst und alles ist nach der Migration aufrufbar.

Des weiteren werden die Statistiken aktualisiert, man sieht also auch die Anzahl an Bestellunge, den Gesamtumsatz etc. - also alles was der Kunde in den 10 Account erzeugte.

Ich gebe Dir Recht, man kann nicht alles automatisieren, aber man muss auch nicht alles manuell machen was eine Software auf Basis eindeutiger Vergleichbarkeit erledigen kann.

Den ersten Step haben wir somit automatisiert und das ist bei den meisten der größte Brocken und der wird, gerade durch Registrierung ohne Account oder Sofortaufträge, nicht kleiner.

 

[wawi-dl]

... aktuell arbeiten wir die Daten ab und prüfen nach eMail Dubletten, den das ist ein Unique Wert auf dem man sich verlassen kann. ...

Ja sorry, bringt mir dann aber nichts, habe ich oben bereits oben genannt.

... Eine Frage habe ich aber, wenn bei Dir ein Kunde 10x ohne Registrierung bestellt hat und so 10 Konten in JTL erzeugt, führt dann Dein Steuerberater zu jedem Konto des Kunden in JTL ein Debitoren Konto? Wenn das so wäre dann würde beim Steuerberater doch einiges schief laufen. ...

Leider falsch, das hat mit Registrierung in einem Shop nichts zu tun. außer die Angaben sind abweichend.
Wir führen hier 2 völlig unterschiedliche Diskussionen, es dreht sich hier um die gebildeten Summen in der Wawi und beim StB!
Wenn du in der Wawi Kunden/Debitoren zusammenfasst, muss das auch der StB tun.
Hast du dich mal mit JTL2Datev beschäftigt? Der Steuerberater prüft doch nicht, ob Kunden/Debitoren bereits existieren, er verbucht den vorliegenden Buchungsstabel, ICH muss diesen doch aufbereiten.
Wenn DU jetzt im Nachgang alle Dubletten bereinigst, ändern sich somit auch die Summen pro Debitor --> also beim Steuerberater dann falsch. (oder ich sehe es falsch)

Wenn man den gleichen Kunden zum letzten Account migriert über den er die letzte Bestellung tätigte, dann hat man sichergestellt das man den aktuellsten Account verwendet.
Ich teilte Dir pauschal mit das wir alles übernehmen was Du in der Kundenansicht sehen kannst, dazu zählen Bestellung, die Artikel der Bestellungen, die Retouren die Stornos usw. einfach alles was du dort sehen kannst und alles ist nach der Migration aufrufbar.

Des weiteren werden die Statistiken aktualisiert, man sieht also auch die Anzahl an Bestellunge, den Gesamtumsatz etc. - also alles was der Kunde in den 10 Account erzeugte.

Nein sorry, der JTL SP oder Knopf in Wawi fasst Kunden zusammen, Aufträge werden alle auf das Konto vererbt, das ist Standard und nicht das Thema!
Warum erhalte ich denn in JTL das Übersichtsfenster, wenn ich etwas zusammenfasse? Richtig, weil ich Entscheidungen treffen muss!

Es darf eben NICHT einfach blind der letzte Account mit Daten drüber gebügelt werden, weil dann Emailadresse und eBay-Username verloren gehen können.
Ich hab viele Stammkunden mit gut gepflegten Stämmen, die will ich doch nicht mit "Müll" von eBay überschreiben.

Siehe hier
https://issues.jtl-software.de/issues/WAWI-33888
https://issues.jtl-software.de/issues/WAWI-51311

Leider wäre für uns somit das Tool unbrauchbar, das Risiko ist zu hoch, da müssten diversen Zusatzregeln hinerlegt sein.

Läuft denn eure Software ohne UI einfach blind im Background?
Was ist mit Backups?

Ich denke du weist sicher selbst, dass es kein RollBack-Szenario gibt, einmal zusammengefasst dann hast du Pech!

Sicherlich kommt die Aussage "vorher ein Backup" machen, hilft mir aber nicht wenn Fehler nicht sofort auffallen.
Die Software wird dann ja ziemlich sicher mit dem Hinweis "auf eigene Gefahr, keine Haftung ..." vertrieben, ich als Kunde sitze dann blöd da.
Drittsoftware -> JTL muss dann erst prüfen ob ein Support überhaupt stattfinden kann, wobei Support in fast jedem Fall hinfällig ist.

Echt eine gute Idee, aber ihr solltet euch absichern und bin gespannt wie ihr das lösen wollt.

 

[MichaelH]

" Eine Frage habe ich aber, wenn bei Dir ein Kunde 10x ohne Registrierung bestellt hat und so 10 Konten in JTL erzeugt, führt dann Dein Steuerberater zu jedem Konto des Kunden in JTL ein Debitoren Konto? Wenn das so wäre dann würde beim Steuerberater doch einiges schief laufen. "

Jedes Kundenkonto ist ein Debitorenkonto.

Grundsätzlich würde ich eine nachträgliche Änderung kritisch sehen.

Es müsste so sein wie "früher", dass beim Übernehmen der Aufträge eine Dublette erkannt wird und vor Auslieferung / Fakturierung die Konten zusammengeführt werden (können).
Leider hat JTL uns diese Möglichkeit genommen, womit wir eine neue Lösung bräuchten.

Dies geht dann auch hinein in die Bonität zu prüfen und auch in die Kundenbewertung, denn heute kann man ggf. einen Stammkunden ohne Kundenkonto gar nicht als solchen erkennen.

Also - alles zusammen wurde leider schlechter und weniger transparent statt besser von Seiten JTL, statt die Funktion auszubauen oder in die Auftragsbearbeitung zu integrieren, wurde sie komplett abgeschafft.

 

[wawi-dl]

Diese alte Kamelle wollte ich nicht ansprechen, aber ich vermisse die frühere Vorschlagsliste auch, dass man gleich reagieren konnte.

Genau aus dem Punkt, bleiben bei mir die Daten wie Sie sind, Workflows mit diversen Regeln prüfen Dubletten und senden uns eine Mail, das funktioniert zu 99,5%.
(Wir arbeiten zum Glück nicht mit Debitoren, ich denke hier nur für potentielle Kunden "mit".)

 

[itratosTeam]

Hallo Wawi-DL,

ja natürlich hat es ein UI und das Programm erzeugt zuerst eine csv Datei die alle Kundenkonten erfasst die als doppelt erkannt wurden. Dann kann man das Programm starten und die erzeugte CSV abarbeiten lassen - das Programm weist darauf hin das man zuerst ein Backup machen soll bzw. ich persönlich empfehle allen derartige Aktionen zuerst in einer reinen DEV Umgebung zu testen.
Das Programm bügelt auch nicht einfach das neuste Kundenkonto über die alten Konten, es migriert von alt nach neu alle Daten der alten Konten.

Da wir viele Lösungen umsetzen die mit JTL interagieren z.B. wie diesen Konfigurator für Präsentkörbe https://www.jamon.de/Praesentkoerbe/Individuelle-Praesentkoerbe/ ist uns durchaus bekannt wie weit wir gehen dürfen, ohne die Datenintegrität zu beeinträchtigen.

Die Idee zu der Lösung kam eigentlich wegen der Bonusprogrammlösung https://www.ondua.de/Bonuspunkte/ da sich viele Kunden zuerst ohne Registrierung im Shop anmeldeten und kauften und erst später zu einem Account entschieden haben um das Bonusprogramm nutzen zu können.
In diesem Fall hatten wir zwei Konten im Shop und zwei in JTL, was dazu führt das man die Bonuspunkte die dem Kunden aus Kulanz in Account 1 nachträglich zugewiesen wurden, nicht mit dem neuen Account abgleichen konnte. Wenn der Shopbetreiber eine Aktion machte loggte sich der Kunde im neuen Account ein, konnte aber hier nicht auf die Bonuspunkte vom ersten Account zugreifen.

Diese ganzen Probleme lösten wir durch Synchronisation der Kundenkonten und setzen hier auch eine eigene API ein die mit JTL kommuniziert, um sicherzustellen das beide Systeme über synchrone Daten verfügen.

Wenn ein Kunde nach xx Monaten erneut den Shop besucht und sich in seinem Account anmeldet, wird er automatisiert erfasst um erneut die Daten mit JTL abzugleichen, dieser Prozess erfolgt dann im Hintergrund als Cronjob über unsere API mit JTL.

Auch wenn Du Dich wiederholt sehr kritisch und ablehnend zeigst, wir und unsere Kunden haben bisher gute Erfahrungen mit unseren Lösungen gemacht aber Potential um etwas noch besser zu machen gibt es immer.

 

[wawi-dl]

... Auch wenn Du Dich wiederholt sehr kritisch und ablehnend zeigst.....

Das liegt ja auch auf der Hand, dass ich zunächst alles kritisch hinterfrage oder?!
Ihr greift hier in das Herzstück der Datenbank ein, da muss man schon wissen was dann in der DB passiert.
Wir haben das ganze Thema Dubletten ja auch mit JTL bereits öfters besprochen und möglichst alle Risiken gesammelt, sonst würden solche Tickets und FeatureRequests nicht entstehen.

Zudem weichst du leider meinen gezielten Fragen aus und widersprichst dich selbst, was mich eben hellhörig macht.
Es migriert die Daten von alt nach neu, ja was nun genau?
Wird hier erst der JTL SP für das mergen verwendet und dann die restlichen Daten nachgezogen? Wähle ich das in der UI aus?
Verwendet ihr jetzt den reinen JTL SP oder nicht? Oder wie sieht denn hier das Doing/der Ablauf der Software genau aus?

Das Programm bügelt auch nicht einfach das neuste Kundenkonto über die alten Konten, es migriert von alt nach neu alle Daten der alten Konten.

Ja aber was denn nun? Das klingt jetzt wieder so, als würde der JTL SP nicht 1zu1 verwendet werden.
Es ist mir auch noch immer nicht klar, wie Dubletten erkannt werden, welche Kriterien dafür herangezogen werden, es gibt so viele Sonderfälle.
Stell doch bitte mal paar Screenshots ein, beantworte dann doch bitte mal meine ganzen Fragen von oben.

... wir und unsere Kunden haben bisher gute Erfahrungen mit unseren Lösungen gemacht .....

Freut mich auch, leider kann ich aber deine Aussage nicht bewerten, ich weis nicht wieviele Kunden es sind, wären es >100 hat dies eine andere Aussage als 3-10 Kunden.
Dann kommt es drauf an, wie groß diese Kunden sind, Kunden die 10 oder 1.000 Bestellungen am Tag haben?
Sind Kunden dabei, die mit Debitoren beim StB arbeiten?

Ich bin noch immer hoffnungsvoll gestimmt, dass du evtl. auf meine Fragen eingehst, Screenshots zeigst und die Arbeitsweise im Ablauf genauer erklärst

 

[itratosTeam]

Hallo Wawi-DL,

ist doch kein Thema wenn Du fragst, habe es nur etwas ironisch hervorgehoben
Haben heute leider sehr wenig Zeit, aber kurz zu den wichtigsten Punkten

Ich glaube schon das ich Dir bereits einiges beantwortet bzw. bestätigt habe hier kurz im Detail

1. Ja wir nutzen die JTL SP, wir automatisieren diese Aufgabe nur
2. Aktuell läuft es so, man wählt einen Shop der überprüft werden soll, dann eMail Dubletten, dann startet man das Programm
   Jetzt erzeugt das Programm zuerst eine CSV mit allen Kunden die zusammengelegt werden würden - dies dient zur Übersicht und für den nächsten Job
3. Jetzt kann man denh Prozess zur Zusammenlegung starten, in diesem Fall wählt man die zuvor erstellte CSV und startet den Job.
   Jetzt geht das Programm jeden Kunden durch und migriert immer 2 Accounts zum aktuell neusten - es werden hier alle Daten vom alten übernommen und alle vom neuen erhalten.

Habe heute mal mit der Buchhaltung eines nicht gerade keinen Kunden gesprochen - der Steuerberater meint das das zusammenlegen aus Sicht der Buchhaltung kein Problem darstellt. Die vorher über versch. Kundenkonten erzeugten Buchungen sind jetzt auch nur in einem Debitorenkonto verbucht.

Ein andere Kunde meldete sich noch gestern bei mir, für den war wichtig das die Ansprechpartner der versch. Kundenkonten erhalten bleiben, dies prüfte ich mit der Datenbank des Shopbetreibers in unserer Entwicklungsumgebung - auch das wird anständig migriert.

Du meintest das ich mich widersprochen habe, wüsste jetzt nicht wo, aber evtl. habe ich zu dem einen oder anderen Punkt zu ungenau erwidert - dafür möchte ich mich entschuldigen.

Wie gesagt, die Lösung kann und sollte man zuerst in einer DEV testen, also Du magst dahingehen Recht haben das es keine Lösung für alle JTLer ist, aber für die sie eine ist die können sie vorher testen.

 

[wawi-dl]

Danke für deine Ausführungen, paar Dinge sind etwas klarer. Vermisse aber leider noch immer paar Screenshots

Ablauf:
1. Dubletten-Analyse (lediglich auf Basis von Emailadressen)
2. Export von CSV-Report
3. CSV-Sichtung durch Benutzer (gibt es da eine UI mit Hilfe, was sich von vorher zu nachher ändert?)
4. CSV-Überarbeitung durch Benutzer
5. CSV-Abarbeitung durch Tool

OK, also die Dubletten-Suche nur nach Emailadresse wäre für uns nicht zielführend, da gehen wir mit unseren Scripten viel weiter.
Emailadressen können sich oft ändern, zudem muss man auch eBay-Usernamen beachten.
Hier nochmals meinen Appell! Der aktuelle JTL SP arbeitet nicht sauber (bin grade wieder mit Support dran), die eBay-Usernamen sind weg, wenn nach einem eBay-Kauf ein Webshop-Kauf kommt mit neuem Konto.
Konto wird bei JTL gern neu erstellt, wenn sich nur Groß-/Kleinschreibung oder Leerzeichen geändert hat.

Habe heute mal mit der Buchhaltung eines nicht gerade keinen Kunden gesprochen - der Steuerberater meint das das zusammenlegen aus Sicht der Buchhaltung kein Problem darstellt. Die vorher über versch. Kundenkonten erzeugten Buchungen sind jetzt auch nur in einem Debitorenkonto verbucht.

Diese Aussage müsste ich leider bemängeln, der Steuerberater weis zu keinem Zeitpunkt, wann Kunden zusammengelegt wurden, sprich Debitoren verknüpft wurden.
Ansonsten wüsste ich mal gerne, wie und warum ein StB Debotiren zusammenfassen sollte???!!! --> Sorry, kann nicht sein!
Niemals hier blind auf Kundenaussagen verlassen, sofern jemand Debitoren hat, sollte man dies prüfen.

Die Software ist evtl. für den ein oder anderen geeignet, für uns wohl eher nicht.
Vor allem mit der Dubletten-Analyse werden ihr nicht alle Dubletten erwischen, wir fahren da mehrere Analysen gegeneinander.

 

[itratosTeam]

Hallo Wawi-DL,

wie ich schon schrieb kann man den Shop wählen, ich schrieb nicht das wir die gesamten Userdaten fixen
Das sich eine eMail ändern kann ist möglich, aber der Kundenkreis bei dem das passiert bzw. die von eMail Service zu eMail Service hüpfen sind oft keine Stammkunden.

Bei den Kunden die wir betreuen kaufen sehr oft Firmen wiederholt ein, inh dem Fall versch. Mitarbeiter aber immer über die gleiche eMail. Diese versch. Besteller erzeugen durch Registrierung ohne Account immer wieder neue Kundenkonten - dieses Problem sollte vorerst gelöst werden.

Du meintest in einem Deiner Posts das der SP von JTL nicht zuverlässig funktioniert, wenn ich mich nicht irre, gleichzeitig glaube ich gelesen zu haben das Du mitteilst das Du den SP nutzt, wie passt das zusammen - kannst Du mir das näher erklären?

Da sich in Verbindung mit unserer Diskussion ein Kunde mit Amazon und eBay Kunden meldete, der hier eine Lösung zur Migration sucht, werde ich vermutlich bald in der Lage sein auch darauf zu erwidern.
Im Moment kann ich Deine Aussage weder bestätigen noch verneinen, dass der eBay Name beim zusammenfügen von Konten nicht oder nicht immer übernommen wird - Deinen genauen Wortlaut weiß ich aktuell nicht mehr, aber ich glaube das Du etwas ähnliche mitgeteilt hast.

Wenn Du bestimmte Lösungen bereits nutzt, Du erwähntest glaube ich Scripte, dann könnte man ja mal sehen was man davon evtl. doch automatisieren kann.

Was die Aussage des Steuerberaters angeht der die Buchhaltung erledigt, da muss ich mich auf Aussage verlassen. Für den Steuerberater schien nur wichtig zu sein das sich die ganzen Belege nicht ändern z.B. andere Nummern erhalten etc.

Wie man der Beschreibung sehr gut entnehmen kann hat jeder Kunde sein eigenes Konto https://www.buchhaltung-einfach-sicher.de/debitorenbuchhaltung
das bedeutet das die Firma Mustermann, die in JTL 10 Kundenkonten mit Bestellungen besitzt in der Buchhaltung nur ein Konto hat und keine 10.
Ich bin kein Steuerexperte und lasse mich dahingehend gerne von Dir berichtigen, ich sehe keinen Grund der gegen ein zusammenlegen in JTL spricht.