Как организовать хранение и поиск, если у товара много артикулов в 1С?

Программист 1С v8.3 (Управляемые формы) 1С:Управление нашей фирмой Управленческий учет Торговля и дистрибуция
← На главную

В процессе автоматизации торговли часто возникает ситуация, когда одна и та же физическая единица товара может иметь несколько различных идентификаторов. Особенно остро эта проблема стоит в сфере автозапчастей, где один и тот же узел может выпускаться разными производителями, иметь старые и новые номера (замены), а также собственные артикулы поставщиков. Рассмотрим подробнее, как правильно организовать архитектуру базы данных в 1С:Управление нашей фирмой (УНФ) и других конфигурациях на платформе 8.3, чтобы обеспечить удобство хранения и высокую скорость поиска.

Проблема множественных артикулов

Когда мы сталкиваемся с тем, что у товара более 2-3 артикулов (в некоторых случаях их количество доходит до 20 и более), стандартное поле Артикул в карточке номенклатуры перестает справляться со своей задачей. Запись всех номеров через пробел или запятую — это путь, ведущий к деградации производительности и ошибкам поиска. Проанализируем, почему это происходит:

  1. Сложность поиска: Полнотекстовый поиск (ППД) может некорректно обрабатывать спецсимволы (тире, точки, пробелы), которые часто встречаются в артикулах.
  2. Отсутствие структуры: Невозможно понять, какой артикул принадлежит конкретному производителю или поставщику.
  3. Проблемы с уникальностью: Сложно контролировать дублирование данных.

Разберем по шагам наиболее эффективные способы решения этой задачи.

Способ 1. Использование типового механизма «Номенклатура контрагентов»

Если ваша конфигурация (например, УНФ или УТ 11) поддерживает функционал номенклатуры поставщиков, это первое, на что стоит обратить внимание. В этом случае для каждой позиции вашей номенклатуры можно создать неограниченное количество записей в подчиненном справочнике НоменклатураКонтрагентов.

Выясним преимущества этого метода:

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

Способ 2. Создание регистра сведений «Аналоги и замены»

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

Посмотрим на пример кода, который выполняет нормализацию артикула при записи в такой регистр. Это критически важно для качественного поиска:


Функция НормализоватьАртикул(Знач ИсходныйАртикул) Экспорт
    // Удаляем все символы, кроме букв и цифр
    ДопустимыеСимволы = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ";
    Результат = "";
    ИсходныйАртикул = ВРег(ИсходныйАртикул);
    
    Для Индекс = 1 По СтрДлина(ИсходныйАртикул) Цикл
        Символ = Сред(ИсходныйАртикул, Индекс, 1);
        Если Найти(ДопустимыеСимволы, Символ) > 0 Тогда
            Результат = Результат + Символ;
        КонецЕсли;
    КонецЦикла;
    
    Возвращает Результат;
КонецФункции

При поиске товара менеджер вводит номер в любом формате (например, "0 123-456"), система нормализует ввод в "0123456" и мгновенно находит соответствие в регистре сведений через проиндексированное поле АртикулПоиск.

Способ 3. Дополнительная табличная часть

Если количество артикулов невелико и вам не нужно связывать их с брендами, можно добавить в справочник Номенклатура дополнительную табличную часть (ТЧ). Рассмотрим этот вариант подробнее. В ТЧ создается одна колонка ДополнительныйАртикул.

Важный момент: Для того чтобы поиск работал быстро, для этой колонки необходимо включить индексирование. Также рекомендуется включить использование полнотекстового поиска для этой табличной части в свойствах объекта метаданных.

Сравнение методов поиска: ППД против запроса

Многие начинающие разработчики полагаются на ПолнотекстовыйПоиск (ППД). Однако в случае с короткими артикулами (3-4 символа) ППД часто работает некорректно или возвращает слишком много лишних данных. Выясним причину: алгоритмы ППД ориентированы на поиск слов в текстах, а не точных идентификаторов.

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


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	Аналоги.Номенклатура КАК Товар,
    |	Аналоги.Артикул КАК НайденныйАртикул
    |ИЗ
    |	РегистрСведений.АналогиНоменклатуры КАК Аналоги
    |ГДЕ
    |	Аналоги.АртикулПоиск ПОДОБНО &ТекстПоиска + ""%""";

Запрос.УстановитьПараметр("ТекстПоиска", НормализоватьАртикул(ВводПользователя));
Результат = Запрос.Выполнить().Выгрузить();

Интеграция с внешними базами (Кроссы)

Для высоконагруженных систем по продаже запчастей хранение 20 артикулов на каждую позицию может привести к раздуванию базы данных. В таких случаях мы рекомендуем использовать интеграцию с внешними сервисами, такими как TecDoc или API крупных поставщиков. Это работает следующим образом:

  1. Менеджер вводит артикул в поиске.
  2. Система отправляет запрос во внешнюю базу данных.
  3. Внешняя база возвращает список всех возможных замен (кроссов).
  4. 1С ищет эти замены среди остатков на собственных складах.

Такой подход позволяет не хранить миллионы связей в локальной базе 1С:УНФ, сохраняя при этом актуальность данных о взаимозаменяемости деталей.

Выводы и рекомендации

Подведем итог нашему исследованию. Выбор метода хранения зависит от ваших бизнес-целей:

Главное правило: всегда очищайте артикулы от спецсимволов перед записью в индекс поиска. Это обеспечит точность результата независимо от того, как пользователь ввел запрос — с пробелами, тире или точками.

← На главную