Добрый день. Пишу выгрузку из клиента банка. Разбираю назначение платежа. Есть например в назначении номер договора М-2305/12-01. Куча контрагентов может поставить на английском  "М" и при разборе этой строки не находит договором у нас в базе, изза того что у нас "М" русская, как можно сделать так чтобы при поиске не обращала внимание на язык или это нереально?((

(0) Можно поискать 2 раза с разными вариантами

(0) табличку соответствий запили.

если не нашел, проверку на похожие буквы, если нашли - замена

А вообще есть КодСимвола() на всякий случай

этож какой геморрой...

(5) Больший геморрой заставить всех контрагентов правильно писать номер договора в назначении платежа.

(6) пытались, бесполезно....

(5) А что, лучше руками чтоли обрабатывать...

+(6) Это я о некоторой бессмысленности такого действа, как парсинг назначения и формирования или поиск чего-то по напарсенным значениям

заменяй все похожие буквы на английские

(9) Тут ты совсем не прав

(8) я вообще предлагал каждому договору присваивать циферный номер, но блин началось договра менять итд итп, и теперь вот сижу велосипед изобретаю.. кто как хочет так и пишет в назначениии, а у нас 1 контрагент =  1 договор , соответственно контрагентов с 1 инн может быть до 100 штук....

(12) +  а маску в назначении только некоторые соблюдают

(11) Если ты задрессируешь контрагентов не ошибаться, не только в анг/рус а вообще в цифрах, черточках и прочем. То да, подход катит.

Можно зафигачить в счета идентификатор и парсить его. Например, "Оплата по договору М-2305/12-01 #33451".

(15) у нас есть код агента, но проблема в том что в 1с контрагентов тонна одинаковых... Поэтому приходится добавлять поиск для договора, я беру номер договора и ищу его в назначении платежа, но вот многих отсекает имеено из этих англ букв

(16) Ну так создай уникальный идентификатор договора, состоящий из одних цифр.

(17)  да написал уже, и назначении придумал типа кодагент//коддоговора//чехотите то пишите, но комерсанты, юристы начали ругаться что в договоре такое не прописано и тд итп, кароче отказались пока...

(16) Так а в чем проблема после неудачного поиска по исходному номеру конвертировать этот номер (меняя кириллицу на латиницу) и снова искать?

(17) че мучить систему, уид есть для особо клинических случаев

(19) Проще сначала заменить, а потом искать

(19) Там же может быть часть символов в латинице, часть в кириллице.

(21) Особенно, если в номере больше одной буквы, а контрагент в платежке одну написал кириллицей, а вторую - латиницей...

(0) как вариант воспользоваться механизмом полнотекстового поиска (с задание ограничения по объекту метаданных). Там все само делается и учитывается. Либо подгонять условие like.

Вариант административный решения - добиться, чтобы цифровая часть номера договора была уникальной и выполнять поиск только по ней, в твоем примере '23051201'.

(5) Не такой уж и геморой. Одна функция. Передаешь ей строку, она в ней все буквы которые не однозначно можно написать, приводит например к русскому или английскому. И только потом по полученной строке ищешь в базе у себя. Надеюсь в базе правила по заведению номеров договора соблюдаются?

(26) надеюсь основополагающее слово

(26) да руками в 1с ничего не попадает, все грузится из учетной базы нашей

(27) Проверишь, если не соблюдаются - приведешь в соответствие. У себя-то в базе ты царь и бог. :)

(29) Тока перед божественным вмешательством рекомендуется делать бэкапы, а то знаете ли, боги разные бывают)