В процессе автоматизации торговли часто возникает ситуация, когда одна и та же физическая единица товара может иметь несколько различных идентификаторов. Особенно остро эта проблема стоит в сфере автозапчастей, где один и тот же узел может выпускаться разными производителями, иметь старые и новые номера (замены), а также собственные артикулы поставщиков. Рассмотрим подробнее, как правильно организовать архитектуру базы данных в 1С:Управление нашей фирмой (УНФ) и других конфигурациях на платформе 8.3, чтобы обеспечить удобство хранения и высокую скорость поиска.
Когда мы сталкиваемся с тем, что у товара более 2-3 артикулов (в некоторых случаях их количество доходит до 20 и более), стандартное поле Артикул в карточке номенклатуры перестает справляться со своей задачей. Запись всех номеров через пробел или запятую — это путь, ведущий к деградации производительности и ошибкам поиска. Проанализируем, почему это происходит:
Разберем по шагам наиболее эффективные способы решения этой задачи.
Если ваша конфигурация (например, УНФ или УТ 11) поддерживает функционал номенклатуры поставщиков, это первое, на что стоит обратить внимание. В этом случае для каждой позиции вашей номенклатуры можно создать неограниченное количество записей в подчиненном справочнике НоменклатураКонтрагентов.
Выясним преимущества этого метода:
Для реализации поиска по этим полям в документах продажи потребуется небольшая доработка подбора, чтобы запрос искал вхождение артикула не только в основной карточке, но и в подчиненном справочнике.
Для специфики автозапчастей наиболее правильным архитектурным решением будет создание отдельного Регистра сведений. Это позволит хранить не просто список строк, а структурированную информацию о кросс-номерах. Проанализируем примерную структуру такого регистра:
Номенклатура (ссылка на вашу карточку товара).Бренд (справочник производителей).Артикул (строка, по которой будет идти поиск).АртикулПоиск (нормализованная строка без спецсимволов).Посмотрим на пример кода, который выполняет нормализацию артикула при записи в такой регистр. Это критически важно для качественного поиска:
Функция НормализоватьАртикул(Знач ИсходныйАртикул) Экспорт
// Удаляем все символы, кроме букв и цифр
ДопустимыеСимволы = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ";
Результат = "";
ИсходныйАртикул = ВРег(ИсходныйАртикул);
Для Индекс = 1 По СтрДлина(ИсходныйАртикул) Цикл
Символ = Сред(ИсходныйАртикул, Индекс, 1);
Если Найти(ДопустимыеСимволы, Символ) > 0 Тогда
Результат = Результат + Символ;
КонецЕсли;
КонецЦикла;
Возвращает Результат;
КонецФункции
При поиске товара менеджер вводит номер в любом формате (например, "0 123-456"), система нормализует ввод в "0123456" и мгновенно находит соответствие в регистре сведений через проиндексированное поле АртикулПоиск.
Если количество артикулов невелико и вам не нужно связывать их с брендами, можно добавить в справочник Номенклатура дополнительную табличную часть (ТЧ). Рассмотрим этот вариант подробнее. В ТЧ создается одна колонка ДополнительныйАртикул.
Важный момент: Для того чтобы поиск работал быстро, для этой колонки необходимо включить индексирование. Также рекомендуется включить использование полнотекстового поиска для этой табличной части в свойствах объекта метаданных.
Многие начинающие разработчики полагаются на ПолнотекстовыйПоиск (ППД). Однако в случае с короткими артикулами (3-4 символа) ППД часто работает некорректно или возвращает слишком много лишних данных. Выясним причину: алгоритмы ППД ориентированы на поиск слов в текстах, а не точных идентификаторов.
Проанализируем ситуацию, когда поиск через запрос к регистру сведений будет эффективнее. Мы можем использовать конструкцию ПОДОБНО для поиска по части артикула:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Аналоги.Номенклатура КАК Товар,
| Аналоги.Артикул КАК НайденныйАртикул
|ИЗ
| РегистрСведений.АналогиНоменклатуры КАК Аналоги
|ГДЕ
| Аналоги.АртикулПоиск ПОДОБНО &ТекстПоиска + ""%""";
Запрос.УстановитьПараметр("ТекстПоиска", НормализоватьАртикул(ВводПользователя));
Результат = Запрос.Выполнить().Выгрузить();
Для высоконагруженных систем по продаже запчастей хранение 20 артикулов на каждую позицию может привести к раздуванию базы данных. В таких случаях мы рекомендуем использовать интеграцию с внешними сервисами, такими как TecDoc или API крупных поставщиков. Это работает следующим образом:
Такой подход позволяет не хранить миллионы связей в локальной базе 1С:УНФ, сохраняя при этом актуальность данных о взаимозаменяемости деталей.
Подведем итог нашему исследованию. Выбор метода хранения зависит от ваших бизнес-целей:
НоменклатураКонтрагентов.Главное правило: всегда очищайте артикулы от спецсимволов перед записью в индекс поиска. Это обеспечит точность результата независимо от того, как пользователь ввел запрос — с пробелами, тире или точками.