dazze

Hallo,
für eine Zahlungseingangsprüfung habe ich versucht eine Funktion zu schreiben die mir aus einem String alle möglichen Kombinationen nach Ersetzen der deutschen Umlaute als Array zurückgibt. Bei CSV Export-Daten die Banken bereitstellen, sind oft deutsche Umlaute entfernt bzw ersetzt. Die Kundendaten, mit denen ich den Abgleich vornehmen will, sind aber mit Umlauten in meiner Datenbasis vorhanden.

Mal ein Beispiel.

Ich habe einen Kundendatensatz für "Müller".

Der Bankexport liefert mir nun einen Datensatz "Mueller" (oder wie auch oft vorkommt "Muller")

Ich bräuchte eine Funktion die mir alle Variationen dieses Namens wiedergibt.

Für den String "ABOBUB" beispielsweise gibt es ja schon X mögliche Varianten

ÄBOBUB
ABÖBUB
ABOBÜB
ÄBÖBUB
ÄBOBÜB
....

Hat jemand ne Idee wie ich sowas am besten umsetze?

Mister Ad

nikosch

Willkommen.

Um dann was mit den zurückgerechneten Bezeichnern zu machen?

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

David

Erstmal zwei Gedanken zum Thema, die Dir (fürchte ich) nicht weiterhelfen werden (aber vielleicht ja doch, vielleicht wenigstens eine Richtung).
a) Frag mal bei der Bank nach, ob sie die Probleme selbst auch haben und durch menschliche Ressourcen lösen (d.h. die Mitarbeiter wissen, was sie eingeben müssen). Wenn nicht, ist "nur" der Export kaputt. Dieses Wissen nutzt Dir allerdings nur etwas, wenn Du auf den Vorgang Einfluss hast.
b) Wenn man in MySQL (es gubt auch andere Datenbanken, bei denen man ähnliches machen kann) eine Tabelle/ein Feld zum Beispiel mit der Collation latin1_german2_ci anlegt (dafür sorgt, dass diese Collation beim Vergleich benutzt wird), findet ein x='Mueller" auch einen Datensatz mit x='Müller'. Wenigstens das Stichwort "Collation" kannst Du mitnehmen. Es handelt sich dabei mehr oder weniger um eine Tabelle, welche Zeichen als "gleich" anzusehen sind.

dazze

Prüfen ob ein Eintrag im eigenen Kundenstamm vorhanden ist.

Also: Bankingexport liefert den String "Muller" - die gesuchte Funktion liefert mir array("Muller", "Mueller", "Müller") ... dieses Array gleiche ich mit meinen Kundendaten ab und finde dann auch den "Müller" den ich im Kundenstamm habe

dazze

Hi David,
danke für die Ideen.

also dass die Banken Ihre Exportdateien nicht per Hand korrigieren ist denke ich nachvollziehbar.
Ich verarbeite dutzende verschiedene Bankingexporte, da gibts wirklich etliche Kombinationen in welcher "Qualität" die Daten ankommen - per Hand korrigieren will ich den Usern der Software nicht wirklich zumuten, da es durchaus mehrere hundert Datensätze jeden Tag sind.

Den Ansatz per SQL hatte ich auch schon, allerdings ist das für den speziellen Fall nicht machbar, ich muss also Strings miteinander vergleichen.

David

Das habe ich auch nicht vermutet Meine Frage war, ob die Daten, die innerhalb der Bank verwendet werden, "richtiger" sind als die Exportdaten, die Du erhälst. Es ist ja durchaus möglich, dass intern Müller immer als Müller gespeichert ist, aber der Exportmechanismus irgendwas zwischen "ärgerlich" und "falsch" ist.

dazze

Der "Exportmechanismus" liegt ja bei der Bank. (Fast) jede Online-Bank stellt Ihren Kunden ja Export-Dateien zum Download bereit. Dadrin sind aber meist 1:1 die Daten die die Bank auch "intern" verwendet. Umlaute werden ja in Überweisungen etc meist eh gewandelt. Dann gibt es noch Exporte zb aus Starmoney (also per HBCI) die Resultate sind im Prinzip die selben, wie direkte Exporte der Bank.

Der Grossteil der Daten aus Bankingexporten sind OK, aber bei einigen gibts halt immer wieder mal Datensätze mit Umlaut-Fehlern.

nikosch

Du willst den Namen anhand eines Eintrags mit bspw. euren Datensätzen aber hinsichtlich eines existierenden KTO/BLZ Schlüssels abgleichen, oder wie? Ohne diese Schlüssel ist das ja sinnlos, wieviele Müller gibt es...

Das denke ich nicht. Eher werden die Banken da relaxt mit umgehen. Schließlich werden solche Daten von handschriftlich ausgefüllten und maschinell ausgelesenen Überweisungsträgern ja auch oft fehlerhaft erkannt. Ein weit verbreitetes Problem sind da bspw. Großbuchstaben, wo z.B. keiner für das ß existiert. Da wird dann schnell mal ein B draus.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

David

Ah, an solche Daten habe ich garnicht gedacht. Da ist definitiv was dran.

cycap

Also die SQL-Variante find ich gar nicht schlecht:

liefert 1 zurück


liefert 0