Всем привет!
Требуется сделать поиск товаров в справочнике номенклатуры по наименованию. Наименование берется из строк внешнего файла поставщиков. Соответственно оно не совпадает с наименованием в нашей 1С.
Нужно в результате поиска показать пользователю наиболее подходящие позиции, т.е. где совпало больше всего слов. Какие тут могут быть варианты?

Первое что приходит на ум - это разбить строку поиска на слова и искать каждое слово по вхождению его в наименование справочника номенклатуры. Для найденных позиций вести счетчик, сколько раз эта позиция была найдена при поиске по каждому слову из искомой строки. Но этот метод наверное очень тяжелый для больших справочников.

Второе что пришло на ум - использовать полнотекстовый поиск. Но я им никогда не пользовался. Почитал, и понял, что он удобен, когда можно ставить всякие условия "И/ИЛИ/расстояние между словами" и прочие. Вроде не совсем то что надо. Ведь программа не знает, что в искомой строке должно войти в наименование полностью, а что нет, что должно быть рядом, а что необязательно.

Поделитесь идеями, кто реализовывал подобное. Какой алгоритм использовали?

Может быть обнаружите что-то подходящее в обработке с ИТС "Поиск и замена дублирующихся элементов" в режиме неточного совпадения.

(0) ну как вариант можно попробовать разбить строку на слова, потом обрезать какой то процент букв спереди и сзади, и вставить в запрос через подобно например "Масло сливочное" преобразовать в "%асл%%ливочн%" и так несколько комбинаций через ИЛИ "%ливочн%%асл%"

(2) + хз насколько долго будет работать... просто как идея

(0) Полнотекстовый поиск прекрасно подходит.

v8: Оператор ПОДОБНО в запросе

http://forum.infostart.ru/forum26/topic70945/

(0) я за полнотекстный поиск, как и (4). Как раз то, что надо!

(1) эту обработку как раз смотрю, спасибо. Но пока не разобрался в ней по поводу неточного совпадения, навороченный код. Знать бы алгоритм, легче самому написать, чем в чужом коде разбираться.

(2) У нас специфика такая, что слова как правило без ошибок. Но вот местами могут быть поменяны, или вообще некоторые слова заменены другими. И слов в наименовании очень много как правило. Поэтому думаю можно не обрезать начало и конец для убыстрения поиска. Ещё есть и объемы, например "1 литр". Но есть точно такие же "0,5 литра", "5 л", ... Тут мне придется писать алгоритм по выцарапыванию объема, это уже другая история. Но вот решить бы общую проблему поиска по словам

(4),(6) Каким образом? Т.е. разбить строку поиска на слова и сделать полнотекстовый поиск с условием ИЛИ? Это будет быстрее, чем я описал в (0) в первом варианте?

(5) про ПОДОБНО в курсе. Вопрос как его оптимально применить

(7) Во-первых определись, тебе нужна "скорость" или "оптимальный поиск". Как правило одно с другим не пересекаются.

наименования поставщиков где-то надо сохранить и потом егорить по ним полнотекстовым поиском

(7) + При работе с "Полнотекстовый поиск" можно задавать "критерий неточности" - это уже реализовано.

(8) да всё нормально, не надо драмы

(11) НУ вот, а я уже вошел в роль и хотел обратиться к "Ёрику" :)

да, бедный Йорик не знал про полнотекстовый поиск и от того вечный покой совершенно не вовремя, да и не его он искал. Эта история про полнотекстовый поиск риальне трагична

...вечный покой НАШЕЛ совершенно...

(14) Трагическая драмма в 5 актах...

(8) Скорость мне важна. Выражение "оптимальный поиск" я вроде не применял, да и не знаю что оно значит. Мне не нужен быстрый поиск, который будет выдавать тыщу ненужных мне товаров. В этом случае лучше медленный поиск, но чтоб на выходе была реально полезная информация. Это я и понимаю под оптимальностью, чтобы результат удовлетворял и по возможности это было быстро.
(9) Раньше хранили различные настройки под каждого поставщика, теперь уходим от этого, должно быть универсально.

(16) Рассмотрите алгоритмы нечеткого поиска

(10) полнотекстовый индекс наскольок я себе представляю - не обновляется мгновенно. возможны "дыры".
.
юзай strmatch - в 8-ке тоже работает. Ищет даже в том случае, если слова не совпадают, т.е. найдет совпадение для

эппл и apple

пример, см здесь:
http://infostart.ru/public/14255/

также на Исе лежат подобные обработки и с полнтекстовым посиком на 8-ке и со стрматч

Щас Маня пролдаст очередную не работающую хрень за полляма, смотрим внимательно!

(18) тоже пока не понял, надо ли каждый раз индексировать перед использованием полнотекстового поиска, если после последнего индексирования в базу были добавлены новые товары. Это конечно неудобно.
Про strmatch читал, но понял, что вроде бы есть ограничение на разрядность винды, только под 32-х работает.
(20) если только можете поделиться готовыми мыслями :) Готовое решение не подойдет, т.к. всё-равно поиск допиливать под себя нужно.

(23) считай уже поделился. описание решение и есть уже идея, только уже реализованная. можете сделать сами.

я практически 100 процентов дал наводку что и как сделать. и как в итоге выглядит.

(23) допиливать можно и готовое решение. Разница только может отличаться в том что надо будет всего 5 процентов под себя что то сделать, а 95 взять готового.
Либо оценивать тогда сколько уйдет времени на написание с нуля.

(25) Что-то я нигде не увидел 100%-ной наводки.
Как я понял, у Вас ведется список поставщиков, и для каждого поставщика задано соответствие своей номенклатуры и то как она называется у поставщика.
Тогда конечно поиск по номенклатуре поставщика быстро найдет нужную номенклатуру. Но в нашем случае это не подойдет. Я написал об этом в (16).

(27) делал похожий поиск для сопоставления справочника номенклатуры с номенклатурой поставщиков - поиск для одной позиции - подходящих номенклатур из 132 тыс элементов - примерно 3-4 сек. - определяется количество вхождений и вес каждого вхождения - сортируем - выдаем список из необходимого количества подходящих позиций

(28) Т.е. номенклатуру поставщика разбивали на слова и искали вхождение каждого слова в справочнике номенклатуры? А как определяли вес каждого вхождения, по количеству символов? Чем больше символов, тем больше вес?

Почитал о полнотекстовом поиске. Вроде всё понятно.
В моем случае получается следующий алгоритм:
беру наименование товара из файла поставщика, разбираю его на отдельные слова. Затем из этих слов беру только те, которые буду использовать в поиске (тут надо будет придумать алгоритм выбора под наши задачи).
Затем составляю строку поиска. Если грубо, то между всеми словами ставлю "ИЛИ" (на самом деле будет посложнее).
Далее вызываю функцию СоздатьСписок().
Полученный список фильтрую, чтобы в результате остался только справочник номенклатуры, задаю нужную нечеткость. И вызываю метод ПерваяЧасть(), чтоб получить результат поиска.

Всё ли правильно я понял?

Но вопрос: как мне выбрать 5 наиболее подходящих позиций из найденных, и отобразить только их?
Например результат поиска дал мне 100 товаров, но среди них есть и одно вхождение слова из искомой строки, и 10 вхождений. Мне нужно выбрать только те, где больше всего вхождений.
Если бы я делал как предлагал в (0), то я бы при поиске каждого вхождения для каждой найденной позиции подсчитывал число найденных вхождений. Потом отсортировал бы по убыванию, и взял например первые 5 позиций. А при полнотекстовом поиске есть ли такая возможность, либо мне нужно будет вручную потом из результата выбирать наиболее подходящие позиции? Если так, то это большой минус, т.к. при поиске по "ИЛИ" попадет очень много товаров, у которых вообще одно вхождение какого-нибудь незначащего слова.

Ну и вообще просьба к тем, кто полнотекстовый поиск реализовывал, какие минусы этого метода? Или скажем так, с чем придется мириться ради него?
Ну наверное значительно вырастет объем БД, из-за создания индекса (надо будет проверить на какой-нибудь файловой версии).
Нужно будет поддерживать индексы в актуальном состоянии, т.е. делать регламентные задания обновления и слияния индексов по ночам. А перед запуском обработки поиска обновлять хотя бы дополнительный индекс, чтоб не сильно тормозило.

Что ещё?

(18) +1 Организовывал поиск по адресу. Взлетело.

(24) ну как у тебя будет автоматом находить схожесть в МикроСтар и MicroStar - тогда ты точно чемпион будешь ;-)

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

Наверху уже написали:
ПОДОБНО "%тут_текст_поиска%" и т.д.
А если применить этот прием несколько раз, то порядок поиска и место слога будет неважно.

(34) здесь не понял? Ведь в полнотекстовом поиске, как я написал, задается процент неточности. Т.е. если ошибки в наименованиях, в какой-нибудь букве, то это должно найти, если задать например 20%. Или Вы о другом о чём-то?

(35) Т.е. предлагаете разбить наименование поставщика на слова и каждое слово искать через ПОДОБНО? Ну я так и хотел в (0), но мне кажется это самый долгий способ.

(36) Нет, не долгий, второй отбор уже нужно делать с результатом первого и т.д.

Каждое слово будет уменьшать результат поиска, вам ведь важно, чтобы вся номенклатура с нужными словами попала. На скульной базе поиск очень быстрый.

(18) +1, на strmatch.dll делал когда-то в семерке - очень недурно получилось!

(37) Не, результаты первого запроса нельзя использовать. Ведь необязательно все слова из наименования поставщика должны быть в нашем наименовании. Суть как раз в том, чтобы найти в нашей базе то наименование, у которого больше всего вхождений слов из наименования поставщика.
(39) я уже писал, тут про ограничение на 32-х разрядную винду писали, да и вообще на винду как таковую.

(41) "алгоритмы, которые мы попоЛЯНем" - красиво сказано.

(42) (*-)


МассивКлючевыхСлов = глРазложитьСтрокуВМассивПодстрок(КлючевыеСловаСтроки);
    МассивКлючевыхСлов = ПеревестиВРег(МассивКлючевыхСлов);
    КоличествоКлючевыхСлов = МассивКлючевыхСлов.Количество();
    
    УсловиеПолейВводаПоСтроке = "";    
    КолСлов = 0;
    Для инд = 0 По КоличествоКлючевыхСлов - 1 Цикл
        СтрКлючевоеСлово = СокрЛП(МассивКлючевыхСлов[инд]);
                
        Если РежимОбработкиПоиска = 1 Тогда
            КолСлов = КолСлов + 1;
            
            Если КолСлов = 1 Тогда
                УсловиеПолейВводаПоСтроке = УсловиеПолейВводаПоСтроке + " И СпрНоменклатура."+СтрУсловиеПоля+" ПОДОБНО &ПодстрокаПоиска"+Строка(инд);
            Иначе
                УсловиеПолейВводаПоСтроке = УсловиеПолейВводаПоСтроке + " ИЛИ СпрНоменклатура."+СтрУсловиеПоля+" ПОДОБНО &ПодстрокаПоиска"+Строка(инд);
            КонецЕсли;
        Иначе
            КолСлов = КолСлов + 1;

            УсловиеПолейВводаПоСтроке = УсловиеПолейВводаПоСтроке + " И СпрНоменклатура."+СтрУсловиеПоля+" ПОДОБНО &ПодстрокаПоиска"+Строка(инд);    
        КонецЕсли;
        
        Если КолСлов = 1 Тогда
            Запрос.УстановитьПараметр("ПодстрокаПоиска"+Строка(инд),"%"+СтрКлючевоеСлово+"%");
        Иначе
            Запрос.УстановитьПараметр("ПодстрокаПоиска"+Строка(инд),"%"+СтрКлючевоеСлово+"%");
        КонецЕсли;
    КонецЦикла;
    
    ТекстЗапроса =
    "ВЫБРАТЬ
    |    СпрНоменклатура.Ссылка КАК Номенклатура,
    |    СпрНоменклатура.Наименование,
    |    СпрНоменклатура.Артикул,
    |    СпрНоменклатура.Родитель КАК ГруппаСправочника
    |ИЗ
    |    Справочник.Номенклатура КАК СпрНоменклатура
    |ГДЕ
    |    СпрНоменклатура.ЭтоГруппа = ЛОЖЬ
    |    И СпрНоменклатура.ПометкаУдаления = ЛОЖЬ";
    Если РежимОбработкиПоиска = 1 Тогда
        ТекстЗапроса = ТекстЗапроса + "
        |  " + УсловиеПолейВводаПоСтроке;        
    Иначе
        ТекстЗапроса = ТекстЗапроса + "
        |    "+УсловиеПолейВводаПоСтроке;
    КонецЕсли;
    ТекстЗапроса = ТекстЗапроса + "
    |
    |СГРУППИРОВАТЬ ПО
    |    СпрНоменклатура.Родитель,
    |    СпрНоменклатура.Ссылка,
    |    СпрНоменклатура.Наименование,
    |    СпрНоменклатура.Артикул";

(40)  > Суть как раз в том, чтобы найти в нашей базе то наименование, у которого больше всего вхождений слов из наименования поставщика.
/
хреновое будет: наше наименование, которое содержит ВСЕ СЛОВА из наименования поставщика - совсем не обязательно одно и то же.

(43) Есть слово "РАЗЛИЧНЫЕ"  в запросе. Группировать то их зачем? Для сортировки?

(43) Спасибо, но пользоваться "ПОДОБНО" я умею. И такой алгоритм мне понятен, я его сам и предложил в своем первом посте. Мне кажется, что использовать "ПОДОБНО" для каждого слова из наименования поставщика чревато длительным ожиданием.
Поэтому как альтернативу рассматриваю полнотекстовый поиск, и хочу, чтобы знающие люди прочитали мои посты (30) и (31), дали свою оценку. Правильно ли я понял как его применить, и какие трудности или неудобства полнотекстовый поиск несёт.

(44) >> хреновое будет: наше наименование, которое содержит ВСЕ СЛОВА из наименования поставщика - совсем не обязательно одно и то же.
Да, необязательно, но в первоначальную выборку оно попадет, вместе с тем наименованием, которое действительно нужно. Но как этого избежать, тут уж ничего не поделаешь. Там уже пользователь выберет нужное, не думаю что таких ситуаций может быть много. Я думаю dll-ка, которую Вы предложили, тоже не сможет с этим справиться?

(46) я в шоке.
у тебя мозги набекрень. или ты вообще не шаришь что такое полнотекстовый поиск, как он в базе хранится и что из себя представляет. ЭТО ДИКИЙ ТОРМОЗ

+(48) а самый главный вопрос каким нафиг боком ты его собираешся использовать к внешнекму файлу.

Бери и делай раз рассматриваешь. чо целый день мозгни делаешь всем. Я бы уже давно сделал все варианты, что и сделал. но тебе видно поуют. ну вот бери грабли и вперед.
Больше дела меньше слов.

Каждую конретну специфику товаров можно поддать логике. и прописать конкретные алгоритмы, регулярные выражения и так далее.

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

(48) >> у тебя мозги набекрень.
Мдаа, а вот эти грубости к чему? Я Вам не грубил. Или Вам обидно, что я умею делать то о чем Вы говорите? Но я всё-равно сказал "спасибо" за попытку помочь.

>> или ты вообще не шаришь что такое полнотекстовый поиск.ЭТО ДИКИЙ ТОРМОЗ
Именно так, я первый раз с этим сталкиваюсь, и именно по нему прошу совета. Ещё раз повторю: прошу оценить то что я написал в постах 30 и 31. Но только тех, кто с этим сталкивался, кто готов поделиться мыслями и у кого всё в порядке с нервной системой.

(49) >> а самый главный вопрос каким нафиг боком ты его собираешся использовать к внешнекму файлу.
По внешнему файлу у меня нет вопросов. Я уже сделал его распознавание. Мой вопрос в том, как полученное из файла наименование товара поставщика найти в нашей базе. Поиск по наименованию в моем случае - это исключение из правила, частный случай, самый плохо автоматизируемый. И только по нему я прошу совета. Не надо придумывать несуществующих проблем, вопрос у меня конкретный.

>> Бери и делай раз рассматриваешь. чо целый день мозгни делаешь всем
Мозги только у Вас кипят, остальные спокойно обсуждают. Кто-то пытается помочь, кто-то что-то полезное для себя почерпнет. Я в отличие от Вас не люблю изобретать велосипед. Нужно опираться на опыт, двигаться дальше, превзносить что-то своё и делиться им. Возможно кто-то поделится решением или идеей, которой ни в моей ни в Вашей голове нет. Вот например про dll-ку я ничего не знал, а столько людей положительно отозвались, я взял на заметку.

(50) >> Каждую конретну специфику товаров можно поддать логике
Я уже написал, что поиск по наименованию - частный случай, когда данные выходят за грани логики.

за это время загнал бы уже в свойства все эти наименования поставщиков. А вооще парсинг строк штука не сложная но почти всегда уникальная и надо смотреть за что можно зацепиться.

(51) точно мозги набекрень.
особенно порадовало "я от в отличие от вас не изобретаю велосипед"
А что изобретаешь?

Миллион раз уже сказали - нужно раскладывать на слова. Без вариантов.

(47) сможет, если наше наименование большое, а наименование постащика покороче - то индекс совпадения будет мелкий.

Ревалентный поиск не дает 100 процентного результата в принципе.

Я уже 4 года в этой тематике каждый день работаю.
И сторонний софт изучал и в 1С все перерыл включая компоненты (громное слово - всего то навсего воткнутый метод "как его там имени кого то" , который и языком 1С можно написать)

dll не делает запросов к базе.
Этот метод отрабатывается когда уже есть список искомой номенклатуры.
в 1С только два варианта и больше никаких:
либо использовать полнотекстовый родной поиск 1С
либо свои собственные запросы, выборки и сравнения.

Главный итог всего - для того чтобы что то сравнить по ревалентности то нужно получить для начала список приближенных.
Это есть главный шаг.

А уже далее перебирать.
И все равно гарантий нет.
Тк как когда будет загружаться файл с 10 000 товарами, то даже 1 процентов - даже если 10 НАИМЕНОВАНИЙ он из 1000 проставит неправильно, а человек не в состоянии будет 10 000 строк проверить.

то ошибка в 10 товарах, и неправильная загрузка цен например - приведет к полному и безоговорочному пистецу. Когда товар за 30 000 рублей, вдруг случайно продадут за 10 000 рублей.
И директор на двадцатку выпорет, на этом все веселые алгоритмы закончаться.

Если у тебя компьютерные комплектующие (специфика), то ты попал в сказку))

Есть локальный Яндекс-сервер, можно ему наименования скормить, а в 1С HTTP-запросом извлекать. :-)

(57) на 32разрядах (хз что там на 640)стрматч отработает тоже очень хорошо. по всякому лучше чем самопальный поиск по словам.

(58) Женя, ну согласись что херню порешь.
Когда цена ошибки на сопоставлении 1000 наименований - такая что из-за однйо ошибки можно получить люлей, то очевидно, что на сопоставление должно выделяться ДОСТАТОЧНОЕ КОЛВО РЕСУРСОВ.

я делал "иетрационную" процедуру.
натравливал автосравнение, при автосравнении все что ниже определенного порга считал как несопоставленное.
результат "записывал".
результат ранжировал по степени похожести при автоматическом сравнении.
.
далее вработу вступал оператор: ему УДОБНО ПОКАЗЫВАЛИСЬ УЖЕ ПРИВЯЗАННЫЕ СРАВНЕННЫЕ ПОЗИЦИИ. он "говорил" ДА или НЕТ.
.
именно такой подход - а не когда дается список похожих и надо выбрать лучшее.
.
так за два-три круга удавалось привязыватьс очень высоким качеством.
.
при наличии большого количества уже привязанных позиций - любой новый прайс сравнивался не только с моей наоменклатурйо, нои с ужепривязанной номенклатурой - это еще авыше подниммало качество и скорость автопривязки.

(62) ну и какая тут фигня?
Давай тогда так - ты сам конкретно в своей жизни загружал на полном автомате прайс в 40 000 строк! вся номенклатура расходится, половина допустим есть в базе.
И у тебя ИДЕАЛЬНО точь в точь! тютелька тютельку! полностью без ползователя распозналась номенклатура?

(63) в типовой есть справочник и регистр для хранения сопоставлений.
О связанных речи нет. Те что были сопоставлены и записаны в справочник - то пропускаем. Тут никакой вообще проблемы и нет.

(64) не загружал. и ты не загрузишь. я тебе уже подсовывал прайсы торговцев дисками - там такая коноваль шо пипец.
.
хорошей загрузке и сопоставлению поддаются нормализованные прайсы, разложенные по столбикам и прочая.. а когда эксельный файл - это место куда вбить что-то - то ЖПС наступает.
.
самый простой пример когда группы идут не вотдельном столбце а в строках. и вычленить то, что это название группы товаров а не какой-нибуль товар - нереально. приходится смотреть на кучу допуслвоий типа если в первой колонке этой строки пусто а во второй колонке число, а в третьей есть что-то - то третья колонка - это подгруппа ранее определенной группы, потому что группа идентфицирцется двумя пустышками в первой и вторйо колонке. ну и т.д.

в итое - или метаконструктор тако йсложности для пользователя что им нахрен никто не пользуется или в коде очередной "плугинчик" для конкретно этого прайса.

.. устал я от вас и мутотни этой .. пойд книженцию почитаю и спать

(66) у меня пока только не получалось сопоставлять компьютерную технику. Это реальный кабзец.
Метизы и стройматериалы не так сложно. А вот компьютерные - это нереально.
Еще и в 1С есть такая фигня под названием длина наименования максимум в 100 символов.
А полному - это сразу аут. 1С долхнет на неограниченных символах.
А если поставить даже 1024 длину строки - жесть нереальная.

А у компьютерных названия .......

С автором могу на ящик коньяка поспорить что если он включит полнотекстовы+ свои_ все длл в мире )) то задачу не решит на сто процентов.

речь не в авторе - а в том что решений таких в природе не существует.
Все алгоритмы которые кто либо создавал только помогают автоматизировать ручной подбор.

АВТОМАТИЧЕСКИ можно сделать только на основании регулярных выражений!! Что такое регулярные выражения. ШАБЛОНЫ
Это грубо говоря когда полностью весь прайс и вся номенклатура в нем построена по определенному логичному шаблону.

Пример: автошины!

Первое слово - размер
Второе марка
Третье лялял
Четвертое ляляля.
ВОТ по этому примеру ДА! МОЖНО.
Когда весь прайс построен по шаблону который легко разобрать.

А когда там все набекреть ПОЛНОСТЬЮ - как я написал торговля комп переферией, ничего не получится на и близко даже.

Штрихкод не судьба вытащить. ну или хотя бы приходные накладные от поставщика и сравнив с вашими залить наименования поставщика из них.

(53) >> Миллион раз уже сказали - нужно раскладывать на слова. Без вариантов.
Ну дак я это ещё в первом своем посте написал. Спросил совета. Причем тут мозги набекрень? Не хорошо...
(57) >> в 1С только два варианта и больше никаких
И об этом я тоже в первом своем посте написал, что на ум приходит только два варианта. Спасибо что подтвердили, хоть и в грубой форме.
(71) >> Все алгоритмы которые кто либо создавал только помогают автоматизировать ручной подбор
Я это понимаю, именно так и надо. Естественно, что 100%-но автоматически не распознается, тут никто и не спорит.

Вобщем, кроме dll-ки ничего нового я не узнал. По полнотекстовому поиску тоже пока никто ничего вразумительного не сказал, кроме  ProProg: "ЭТО ДИКИЙ ТОРМОЗ".

(72) Не совсем понял о чем речь. Штрих-кода как правило нет в файлах. А грузить будем зачастую именно с приходных накладных поставщика. Ну и не только с них, со счета, счет-фактуры, и любого произвольного формата. И бывает, что кроме наименования зацепиться не за что.

Как я вижу, некоторых начинает раздражать эта ветка, советуют пробовать всё самому, вместо того чтоб здесь писать, поэтому давайте закроем обсуждение :)
Вообще я не просил программного кода, лишь интересно обсуждение возможных алгоритмов, кто и как делал.

(75) какая специфика товаров - чем торгуете?

(0)привязывай соответствие номенклатуры контрагентов к своей с пом. штатного соотв. регистра "номенклатура контрагентов" чтобы всегда работать с новой номенклатурой

+(77)делал просто. обработка грузит на форму из экселя номенклатуру контрагентов, у кого то есть привязка по коду, у кого то по наименованию у кого то по ШК в обработке показываются варианты.пользователь ставит галки и привязывает в РС.

(76) автохимия, автозапчасти
(77) у Вас наверное УТ, там регистр позволяет это делать. Но не суть, регистр можно и свой сделать, мысль понятна, спасибо.