← На главную

Переход с редакции 11.4 на 11.5 в конфигурациях «1С:Управление торговлей» (а также в Комплексной автоматизации и ERP) принес значительные изменения в подсистему лояльности. Одним из самых болезненных моментов для многих пользователей стал переход на новый механизм учета бонусных баллов (так называемая система 2.5). Рассмотрим ситуацию, когда после обновления у клиентов начинают некорректно списываться баллы, возникают отрицательные остатки, а регламентные задания работают непредсказуемо. Разберем причины этого поведения и выработаем алгоритм исправления.

Суть проблемы: двойное списание и отрицательные остатки

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

1. Клиенту были начислены бонусные баллы с ограниченным сроком действия (например, 1 год).
2. В течение года клиент успешно потратил эти баллы на оплату покупок. Остаток баллов стал равен нулю (или уменьшился корректно).
3. Наступает дата, когда эти баллы должны были бы «сгореть» по сроку годности (через год после начисления).
4. В этот момент система внезапно списывает сумму начисленных баллов еще раз, уводя общий баланс клиента в глубокий минус.

Возникает вопрос: почему система пытается списать баллы, которые уже были потрачены? Почему механизм контроля остатков не видит, что списывать нечего?

Различия архитектуры: Старая система vs Новая система (2.5)

Чтобы понять корень проблемы, давайте разберем, как изменилась логика хранения данных в регистре накопления БонусныеБаллы.

В старых версиях (до 11.5.9):
Логика была линейной. Остаток рассчитывался как Приход минус Расход. Списание просроченных баллов осуществлялось физическим созданием документа СписаниеБонусныхБаллов. Вы (или регламентное задание) запускали обработку, она смотрела остатки, видела просрочку и создавала документ списания. Это фиксировало движение «Расход» в регистре.

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

Конфликт возникает, когда в базе данных одновременно действуют следы старой логики и правила новой. Если регламентное задание не смогло корректно распределить расход (покупку) на конкретную партию начисления, то для системы это начисление остается «нетронутым». Когда подходит срок его годности, алгоритм видит: «Ага, было начислено 100 баллов, срок истек, распределения расхода на них нет. Значит, надо списать 100 баллов как просроченные». И делает запись в регистр. В итоге у клиента: -100 баллов за покупку и еще -100 баллов за истечение срока. Итого: -100 баллов в остатке (если исходно было 100).

Анализ причин сбоя

Основываясь на опыте сообщества и технической документации, выделим основные причины такого поведения:

1. Конфликт регламентных заданий. Это самая частая причина. После обновления в базе может остаться настроенное старое задание, которое создает документы СписаниеБонусныхБаллов с правилом «Регламентное списание». Одновременно с этим работает новое задание РаспределениеСрочныхБонусныхБаллов. Они начинают конкурировать за остатки, что приводит к задвоению списаний.
2. Некорректная миграция данных. Обработчик обновления при переходе на новую версию должен был скорректировать регистр БонусныеБаллы, заполнив или очистив ресурс КСписанию. Если после этого продолжили создаваться ручные или автоматические документы списания по старым правилам, данные в регистре разъехались.
3. Ошибки платформы при возвратах. Существует зарегистрированная ошибка (код 00-00694975), когда при распределении срочных баллов некорректно обрабатываются возвраты товаров. Это может приводить к зацикливанию регламентного задания и неверному расчету доступного остатка.

Пошаговое решение проблемы

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

Шаг 1. Остановка старых механизмов

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

Если у вас настроено автоматическое создание документов СписаниеБонусныхБаллов с правилом списания «Регламентное списание» (или подобным), его необходимо отключить. В новой логике (начиная с УТ 11.5.9) отдельный документ списания для просроченных баллов не требуется — этим занимается фоновое задание распределения, которое делает движения по регистрам автоматически или формирует движения через специальные механизмы.

Шаг 2. Очистка лишних документов

Проанализируйте документы СписаниеБонусныхБаллов, созданные за период после обновления (или за период действия текущих срочных бонусов, например, за последний год).

Если эти документы были созданы автоматически по старым правилам параллельно с работой нового механизма, они, скорее всего, лишние. Их необходимо пометить на удаление или распровести. Это действие уберет «ручной» расход баллов, который конфликтует с автоматическим аннулированием.

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

Шаг 3. Включение и проверка нового регламентного задания

Убедитесь, что включено регламентное задание РаспределениеСрочныхБонусныхБаллов. Именно оно отвечает за то, чтобы «погасить» начисленные баллы расходом (оплатой чеком). Пока это задание не отработает корректно, система будет считать, что начисленные баллы все еще лежат на счете клиента нетронутыми. Для устранения последствий сбоев этого регламентного задания можно использовать обработку для автоматического исправления минусов бонусов.

Шаг 4. Корректировка регистра накопления (Самый важный этап)

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

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

• Начислено (или аналог, отвечающий за приход)
• КСписанию (служебный ресурс для отслеживания остатка срока действия)

Если регламентное задание отработало неправильно, вы увидите расхождение. Например, по ресурсу КСписанию остаток есть, а фактического остатка баллов нет. Система видит положительное значение в КСписанию и пытается его обнулить при истечении срока, создавая минус. Для быстрого выравнивания таких остатков можно воспользоваться помощником исправления минусовых бонусных баллов в УТ 11.5.

Решение через документ «Корректировка регистров»:

1. Создайте документ Корректировка регистров.
2. Выберите регистр накопления БонусныеБаллы.
3. Вам необходимо привести конечный остаток ресурса КСписанию к соответствию с ресурсом Начислено (с учетом расхода).

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

В ряде случаев (как указано в полезных сообщениях темы), требуется сделать так, чтобы сумма записей ресурса КСписанию соответствовала ресурсу Начислено. Это позволит регламентному заданию корректно понять: «Ага, вот столько было начислено, вот столько уже списано/распределено, значит, остаток равен нулю».

Шаг 5. Работа с ошибкой возвратов (Bug 00-00694975)

Если у вас были возвраты товаров, оплаченных бонусами, ситуация усложняется. Ошибка 00-00694975 приводит к зацикливанию распределения.

Симптомы:

• Регламентное задание выполняется бесконечно или падает с ошибкой.
• Баллы за возврат не возвращаются на счет или возвращаются дважды.

Для решения этой проблемы рекомендуется:

1. Обновиться до последнего релиза (ошибка зарегистрирована в январе 2025 года, исправления выходят в новых патчах).
2. Если обновление невозможно, проверьте документы ВозвратТоваровОтКлиента. В новой системе критически важно, чтобы возврат был корректно привязан к документу продажи (Чек ККМ или Реализация). Если связь потеряна, система не может найти партию бонусов для сторнирования списания.
3. В некоторых случаях помогает ручное перепроведение цепочки: Начисление бонусов -> Продажа (списание) -> Возврат. Это заставляет механизм пересчитать движения в регистре с учетом новой логики.

Итоговое резюме

Проблема отрицательных бонусов после обновления на УТ 11.5 — это следствие конфликта данных при переходе от «статического» списания к «динамическому».

Что нужно сделать в первую очередь:

1. Прекратить использование документов Списание бонусных баллов с правилом «Регламентное списание».
2. Убедиться, что работает регламентное задание Распределение срочных бонусных баллов.
3. Если баланс уже нарушен — использовать Корректировку регистров, чтобы выровнять ресурс КСписанию согласно фактическому остатку баллов.

Эти действия позволят стабилизировать систему лояльности без необходимости отката на старую версию функционала.