Neues Thema starten

Problem mit Umlauten im Datastore

Hallo Team,

ich nutze zum Abgleich mit Herstellerdateien zu bei meinen Klienten schon existierenden Varianten mehrere Datastores. Mir ist nun aufgefallen, daß beim Import neuer Datensätze in den Datastore manche nicht aufgebaut werden, weil sie scheinbar bereits vorhanden sind - aber nur scheinbar. Das Problem ist hier offenbar, daß der Datastore keinen Unterschied macht, ob es z.B. der Wert "Mélange" oder "Melange" ohne Accent ist; existiert der eine Wert bereits, wird der andere nicht gespeichert. Es wäre aber für einen korrekten Abgleich wichtig, daß beide Werte aufgebaut werden. Kann ich da selber was tun (vielleicht mittels Codierung o.ä.), oder liegt der Ball bei euch?


Danke und Gruß,


Michael Podolsky

podcomm e-commerce management



Man müsste das Suchen/Ersetzen überall machen, wo etwas mit diesem identifier gemacht wird. Also a) wenn er von plenty in den DS geschrieben wird und b) wenn der Abgleich per Querverweis mit der Lieferantendatei gemacht wird. 


Wir nehmen dieses Thema mit auf die Wunschliste für die Zukunft. Aktuell ist keine Anpassung möglich, da es ein tiefer Eingriff in der Datenbank-Infrastruktur wäre (ja, es klingt klein, ist aber riesig). 


Evtl. ist der Step KeyValueSpreadsheet hilfreich (statt SpreadsheetAppend...obwohl uns gerade nicht nicht ersichtlich ist, wie man mit SpreadsheetAppend irgendetwas vergleichen könnte...)

Das ist eben nicht möglich, weil der genaue Attributwert ja im Datastore gesucht werden muß - wenn in der Herstellerdatei "Mélange" steht, muß ich wissen, ob dieses Attribut in plenty schon existiert und, wenn nicht, erstmal per Import aufbauen. In plenty können "Mélange" und "Melange" beide existieren, also müßten auch beide im Datastore stehen, damit das sauber abgefragt werden kann.
Wenn euer Datastore keine umlaute verträgt (warum eigentlich nicht...?), muß ich mir hier anders behelfen und immer erstmal einen Export von Plenty ziehen und die Werte letztlich per SpreadsheetAppend vergleichen - ist umständlich und kostet auch immer einen zusätzlichen Exportstep.

Wir vermuten es geht um den Identifier des Datensatzes. Dort dürfen keine UTF-8 Sonderzeichen enthalten sein, sonst kommt es zu diesem Effekt. 

Workaround wäre, dass man solche Zeichen vorher im SpreadheetMapper per Suchen/Ersetzen ersetzt. Oder falls möglich einen anderen Identifier verwenden, der eindeutig ist und keine Sonderzeichen beinhaltet. 

Anmelden um einen Kommentar zu veröffentlichen