Почему не работает автоподбор совместно продаваемой номенклатуры в 1С:УТ 11 и как это исправить?

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

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

Однако на практике многие системные администраторы и программисты сталкиваются с тем, что регламентное задание выполняется мгновенно, а регистр сведений НоменклатураПродаваемаяСовместно остается абсолютно пустым. В этой статье мы подробно разберем, как устроен этот механизм «под капотом», почему стандартный анализ данных выдает пустую коллекцию правил и как правильно настроить систему, чтобы искусственный интеллект 1С наконец-то заработал.

Как устроен механизм поиска ассоциаций «под капотом»

Для начала проанализируем техническую сторону вопроса. Платформа «1С:Предприятие 8» предоставляет разработчикам мощный встроенный инструмент — объект АнализДанных с типом АнализДанныхПоискАссоциаций. Этот объект использует математические алгоритмы интеллектуального анализа (Data Mining), очень похожие на классический алгоритм поиска ассоциативных правил Apriori.

Работа механизма строится по следующей схеме:

  1. Система обращается к истории продаж за определенный период (анализируются документы «Реализация товаров и услуг», «Чек ККМ», «Заказ клиента»).
  2. Каждая отдельная накладная или чек рассматривается как единая «корзина покупателя».
  3. Алгоритм ищет устойчивые связи вида: Предпосылка → Следствие (например, если клиент покупает товар «А», то с высокой долей вероятности он также приобретет товар «Б»).
  4. Найденные и прошедшие фильтрацию правила записываются в регистр сведений НоменклатураПродаваемаяСовместно.

Программный код, который запускает этот процесс в типовой конфигурации, выглядит следующим образом:


Анализ = Новый АнализДанных;
Анализ.ТипАнализа = Тип("АнализДанныхПоискАссоциаций");

// Настройка источника данных (выборка из документов продаж)
Анализ.ИсточникДанных = ТаблицаДокументовПродаж; 

// Запуск расчета ассоциативных правил платформой
РезультатАнализа = Анализ.Выполнить();

// Обход результатов расчета
Для Каждого Правило Из РезультатАнализа.Правила Цикл
    // Запись связей в регистр сведений
    НоваяЗапись = РегистрыСведений.НоменклатураПродаваемаяСовместно.СоздатьМенеджерЗаписи();
    НоваяЗапись.Номенклатура = Правило.Предпосылка[0].Значение;
    НоваяЗапись.СопутствующаяНоменклатура = Правило.Следствие[0].Значение;
    // ... заполнение остальных реквизитов (значимость, мера доверия)
    НоваяЗапись.Записать();
КонецЦикла;

Если при выполнении этого кода система даже не заходит в цикл Для Каждого Правило Из РезультатАнализа.Правила Цикл, это означает, что объект АнализДанных вернул пустой результат. Выясним, почему это происходит.

Почему коллекция «Правила» остается пустой?

Основная причина отсутствия результатов анализа кроется в жестких математических критериях отсечения «информационного шума», установленных в настройках поиска ассоциаций по умолчанию. Платформа 1С оценивает потенциальные связи между товарами по трем ключевым параметрам:

  1. Минимальный процент случаев (Поддержка / Support): Показывает, в каком проценте от общего количества проанализированных документов продаж должна встретиться данная связка товаров, чтобы система сочла ее закономерностью, а не случайностью. Если у вас в базе 10 000 чеков, а пара товаров продавалась совместно в 50 случаях, то процент поддержки составит всего 0.5%. Если в настройках по умолчанию этот порог равен 2% или 5%, алгоритм безжалостно отсечет эту связь как несущественную.
  2. Минимальная достоверность (Доверие / Confidence): Показывает условную вероятность покупки товара «Б» при условии, что товар «А» уже лежит в корзине. Например, если при покупке принтера картридж к нему докупают в 30% случаев, а порог доверия в системе выставлен на уровне 50%, то данная ассоциация также будет проигнорирована алгоритмом.
  3. Минимальная значимость (Лифт / Lift): Отражает силу правила. Если коэффициент значимости равен 1, это значит, что покупка товара «А» никак не влияет на вероятность покупки товара «Б» (они независимы). Значение больше 1 указывает на сильную положительную связь.

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

Разберем по шагам: как правильно настроить систему

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

  1. Перейдем в раздел CRM и маркетинг → Настройки и справочники → Номенклатура, продаваемая совместно (в зависимости от релиза УТ 11 путь может немного отличаться, например, через администрирование разделов продаж).
  2. Откроем форму Настройка поиска ассоциаций.
  3. Обратим внимание на параметры «Минимальный процент случаев» и «Минимальная достоверность». Если там установлены стандартные значения (например, процент случаев 5%, достоверность 50%), попробуем значительно снизить их чувствительность.
  4. Установим следующие тестовые значения параметров:
    • Минимальный процент случаев: 0.1% (или даже 0.01% для баз с большим ассортиментом и редкими повторениями).
    • Минимальная достоверность: 5% или 10%.
  5. Зададим корректный Период анализа. Не стоит выбирать слишком короткий период (например, неделю), так как алгоритму банально не хватит накопленной статистики продаж для выявления закономерностей. Рекомендуется выбирать период от 3 месяцев до 1 года.
  6. Сохраним настройки и запустим расчет повторно, нажав кнопку Выполнить поиск ассоциаций (или запустив регламентное задание Обновление номенклатуры, продаваемой совместно).

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

Технические нюансы и разделение продаж

Рассмотрим еще несколько важных моментов, о которых часто забывают при внедрении этого функционала:

1. Разделение на оптовые и розничные продажи.
В настройках поиска ассоциаций вы можете указать, какие именно продажи анализировать. Доступны варианты: «Оптовая торговля», «Розничная торговля» или «Оптовая и розничная торговля». Обратите внимание, что если вы настроите и рассчитаете ассоциации только по оптовым продажам, то при подборе товаров в Чеке ККМ (розница) система не предложит сопутствующие товары, так как для розницы они не рассчитывались. Проанализируйте профиль ваших продаж и выберите подходящий вариант.

2. Производительность системы при расчете.
Запуск объекта АнализДанных — это крайне ресурсоемкая операция. Платформа выполняет сложные математические вычисления непосредственно на сервере 1С или СУБД. Если запустить расчет ассоциаций на крупной базе с миллионами записей продаж в разгар рабочего дня, это может привести к критическому падению производительности и зависанию системы. Настоятельно рекомендуем выносить регламентное задание ОбновлениеНоменклатурыПродаваемойСовместно на ночное время или выполнять его в выходные дни (например, раз в неделю).

Альтернативное решение: ручное заполнение и загрузка данных

Как справедливо заметили участники обсуждения на форуме, иногда интеллектуальный алгоритм действительно может работать неидеально или выдавать неочевидные ассоциации, которые маркетологам кажутся нелогичными. Кроме того, в некоторых ранних релизах УТ 11.2 наблюдались технические ошибки платформенного механизма инициализации параметров.

Если запустить автоматический расчет так и не удалось, или вы хотите иметь полный контроль над предлагаемыми сопутствующими товарами, рассмотрите альтернативные варианты:

← На главную