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

← На главную

Многие пользователи и разработчики сталкиваются с крайне неприятной ситуацией: после штатного обновления конфигурации 1С:Управление торговлей (с версии 11.4 или более ранних релизов 11.5 на версии старше 11.5.9.x) полностью ломается механизм бонусной программы. Бонусы перестают начисляться при пробитии чека ККМ, у некоторых клиентов баланс обнуляется или уменьшается вдвое, а при попытке провести смешанную оплату баллы просто не подтягиваются. Давайте вместе разберем эту ситуацию по шагам, выясним причину такого поведения системы и настроим базу для корректной работы программы лояльности.

Проанализируем ситуацию и симптомы проблемы

На первый взгляд ситуация выглядит как критический баг обновления. Пользователи отмечают следующие симптомы:

При розничной продаже бонусы визуально начисляются и даже печатаются в кассовом чеке.
В документе ОтчетОРозничныхПродажах они также учитываются.
Движения в регистр накопления БонусныеБаллы попадают.
Однако! В отчетах об остатках бонусных баллов по конкретному клиенту пусто.
Ручное начисление баллов документом НачислениеИСписаниеБонусныхБаллов делает проводки, но не меняет итоговый остаток клиента.
Тестирование и исправление базы (ТИИ) не дает никаких результатов.

Разберем подробнее истинную причину происходящего. Начиная с релизов УТ 11.5.9 и выше, разработчики фирмы 1С кардинально изменили архитектуру работы с программой лояльности.

Выясним причину: изменение архитектуры и фоновые задания

Раньше, в версии 11.4 и ранних 11.5, все вычисления по бонусам производились непосредственно в момент проведения документа чека или отчета о розничных продажах. Если баллы имели разный срок действия (сгораемые, срочные), алгоритм должен был "на лету" высчитать, какие именно баллы списывать в первую очередь. В высоконагруженных розничных сетях это приводило к серьезным тормозам при пробитии чека.

Чтобы ускорить работу кассиров, ресурсоемкое вычисление было вынесено из транзакции проведения документа в отдельный асинхронный процесс. Теперь при пробитии чека новые баллы формируют "сырые" движения в регистрах в неокончательном статусе. Окончательный расчет баланса клиента и распределение партий бонусов возложено на специальное регламентное задание «Распределение срочных бонусных баллов».

Если это регламентное задание не отработало, система считает, что актуальных, подтвержденных к списанию баллов у клиента нет. Отсюда и нулевые балансы в отчетах.

Посмотрим на «чудо» серверных баз и проблему файловых

На форумах часто можно встретить сообщения, что проблема "решилась сама собой" после перехода с файловой версии базы на клиент-серверную (например, на PostgreSQL). Проанализируем, почему так происходит.

В типовой поставке 1С регламентное задание РаспределениеСрочныхБонусныхБаллов настроено на выполнение один раз в сутки, ночью (чтобы не грузить сервер в рабочее время). В клиент-серверной архитектуре фоновые задания операционной системы выполняются круглосуточно и автоматически. Как только наступает ночь, сервер 1С пробуждает задание, оно пересчитывает все чеки за день, и утром клиенты снова видят свои бонусы.

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

Технические нюансы: регистры и будущие даты

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

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

Если вам необходимо программно проверить или проанализировать "сырые" данные о начислениях (например, при написании кастомного отчета), можно использовать запрос напрямую к регистру, игнорируя механизмы виртуальных таблиц остатков. Рассмотрим пример запроса:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |    БонусныеБаллы.Партнер КАК Клиент,
    |    БонусныеБаллы.БонуснаяПрограммаЛояльности КАК ПрограммаЛояльности,
    |    СУММА(БонусныеБаллы.Начислено) КАК Начислено,
    |    СУММА(БонусныеБаллы.КСписанию) КАК КСписанию,
    |    БонусныеБаллы.Регистратор КАК Регистратор
    |ИЗ
    |    РегистрНакопления.БонусныеБаллы КАК БонусныеБаллы
    |ГДЕ
    |    БонусныеБаллы.Партнер = &Партнер
    |
    |СГРУППИРОВАТЬ ПО
    |    БонусныеБаллы.Партнер,
    |    БонусныеБаллы.БонуснаяПрограммаЛояльности,
    |    БонусныеБаллы.Регистратор
    |УПОРЯДОЧИТЬ ПО
    |    БонусныеБаллы.Регистратор.Дата";

Запрос.УстановитьПараметр("Партнер", ПроблемныйКлиент);
Результат = Запрос.Выполнить();

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

Практические решения: по шагам исправляем проблему

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

Решение 1. Изменение расписания регламентного задания (Основное решение)

Если вы работаете в файловой базе (которую закрывают на ночь) или хотите, чтобы актуальные балансы у клиентов появлялись в течение дня, а не только на следующее утро, выполните следующие действия:

Откройте раздел НСИ и администрирование.
Перейдите в Обслуживание -> Регламентные операции -> Регламентные и фоновые задания.
Найдите в списке задание Распределение срочных бонусных баллов.
Двойным кликом откройте его карточку.
Нажмите на ссылку Расписание.
Измените расписание: укажите выполнение задания каждые 15-30 минут (в зависимости от нагрузки на сервер и интенсивности продаж) в течение рабочего дня.
Сохраните изменения. Выделите задание и нажмите кнопку Выполнить сейчас.

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

Решение 2. Откат к старой логике ценообразования (Не рекомендуется)

Разработчики оставили "аварийный люк" для тех, кто не готов переходить на новые механизмы. В разделе НСИ и администрирование -> CRM и маркетинг -> Маркетинг есть скрытая ссылка «Вернуться на ценообразование версии 11.0».

Важно понимать: эксперты и программисты 1С категорически не рекомендуют использовать этот откат, если после обновления на релиз 11.5 уже было создано множество новых документов, чеков и отчетов о розничных продажах. Возврат старой логики задним числом может привести к серьезным перекосам во взаиморасчетах и регистрах ценообразования. Использовать этот метод можно только в том случае, если вы только что обновились и еще не вели оперативную деятельность в новой версии.

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