← На главную

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

Анализ проблемы: как работает механизм и где возникает сбой

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

1. Начисление бонусов. При начислении срочных бонусов, например, 300 баллов на день рождения, система создает в регистре накопления Бонусные баллы два движения типа "Приход":
   • Первое движение увеличивает ресурс Начислено на 300 баллов на текущую дату. Это фактический баланс клиента, который он может потратить.
   • Второе движение увеличивает ресурс К списанию на те же 300 баллов, но с датой сгорания. Этот ресурс используется системой для отслеживания бонусов, которые должны быть аннулированы по истечении срока.
2. Частичная оплата бонусами. Клиент совершает покупку и оплачивает ее частью бонусов, например, 159 баллами. Документ "Отчет о розничных продажах" (или "Чек ККМ") создает движение "Расход" по ресурсу Начислено на сумму 159. Теперь остаток бонусов клиента — 141 балл.
3. Списание неиспользованных бонусов. Через несколько дней наступает дата сгорания бонусов. Срабатывает регламентное задание "Распределение срочных бонусных баллов". Его задача — аннулировать оставшиеся 141 балл. Оно выполняет сложные корректировки:
   • Оно "дописывает" движение "Расход" на 141 балл по ресурсу К списанию непосредственно в тот "Отчет о розничных продажах", где была частичная оплата.
   • Оно создает собственные движения списания по обоим ресурсам (Начислено и К списанию), чтобы полностью закрыть остатки по сгоревшим бонусам.

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

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

Документ при своем перепроведении полностью перезаписывает свои движения в регистрах. Он "не знает", что регламентное задание что-то к нему "дописало". В результате движение "Расход" на 141 балл по ресурсу К списанию, добавленное фоновым процессом, бесследно исчезает.

Казалось бы, следующее выполнение регламентного задания должно обнаружить проблему и восстановить движение. Но этого не происходит. Логика запроса в задании, по всей видимости, ориентируется на остатки по ресурсу Начислено. А этот ресурс уже корректно закрыт в ноль (159 списано при продаже, 141 списано самим же заданием ранее). В итоге задание считает, что по этим бонусам делать больше нечего, и игнорирует их.

В результате мы получаем некорректную ситуацию: по ресурсу К списанию остается "висеть" незакрытый остаток в 141 балл, что является ошибкой с точки зрения целостности учета.

Почему система спроектирована именно так?

Такая, на первый взгляд, нелогичная схема с "дописыванием" движений фоновым заданием сделана для оптимизации производительности. Проведение документов продажи в реальном времени (особенно в рознице) должно быть максимально быстрым. Сложный анализ того, какие именно бонусы списывать — срочные с ближайшей датой сгорания или бессрочные — вынесен в отдельный, не оперативный процесс. Это позволяет кассиру быстро пробивать чеки, не дожидаясь выполнения сложных расчетов. Однако, как мы видим, у этого подхода есть серьезный побочный эффект, связанный с хрупкостью данных при перепроведении документов.

Смежные проблемы и на что еще обратить внимание

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

• Двойное списание. Встречаются случаи, когда регламентное задание не видит, что часть срочных бонусов уже была потрачена, и пытается списать всю начисленную сумму целиком. Это приводит к возникновению отрицательных остатков на бонусном счете клиента.
• Конфликт регламентных заданий. В старых версиях УТ существовало задание "Автоматическое начисление и списание бонусных баллов". В актуальных релизах (11.5.9 и новее) его функционал перешел к заданию "Распределение срочных бонусных баллов". Критически важно убедиться, что старое задание отключено, и работает только новое. Их одновременная работа может приводить к хаосу в учете бонусов и отрицательным остаткам.

Как решить проблему?

Так как описанная ситуация, скорее всего, является недоработкой или ошибкой в логике типовой конфигурации, универсального решения "одной кнопкой" не существует. Однако можно предпринять следующие шаги для минимизации рисков и исправления ситуации.

Решение 1: Профилактические и административные меры

1. Обновите конфигурацию. В первую очередь, убедитесь, что вы используете последнюю актуальную версию "1С:Управление торговлей 11.5". Возможно, в одном из обновлений разработчики 1С уже исправили эту ошибку.
2. Проверьте настройки регламентных заданий. Перейдите в раздел НСИ и администрирование → Администрирование → Обслуживание → Регламентные операции и фоновые задания. Убедитесь, что задание Распределение срочных бонусных баллов включено и выполняется регулярно (например, каждую ночь), а старое задание Автоматическое начисление и списание бонусных баллов выключено.
3. Избегайте перепроведения документов. Самый простой, хотя и не всегда удобный совет — стараться не перепроводить документы задним числом, если в них была оплата бонусами. Если перепроведение необходимо, будьте готовы к тому, что может потребоваться ручная корректировка.

Решение 2: Ручная корректировка данных (для опытных пользователей)

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

Для этого используется документ Корректировка регистров. Необходимо создать новый документ, выбрать для корректировки регистр накопления Бонусные баллы и вручную добавить движение типа "Расход" на нужную сумму по ресурсу К списанию с указанием соответствующей аналитики (карты лояльности, документа-основания).

Внимание! Этот способ требует глубокого понимания структуры данных и должен применяться с большой осторожностью, так как неверные действия могут еще больше нарушить учет.

Решение 3: Доработка системы с помощью расширения (рекомендуется)

Наиболее надежный и правильный способ решения — это доработка типовой логики с привлечением 1С-программиста. Проблема может быть решена несколькими путями через создание расширения конфигурации:

1. Модификация регламентного задания. Можно изменить запрос в задании Распределение срочных бонусных баллов. Вместо того чтобы ориентироваться только на остатки ресурса Начислено, доработанное задание должно также анализировать расхождения между ресурсами Начислено и К списанию. Обнаружив "зависший" остаток по К списанию, оно должно принудительно создавать корректирующее движение, даже если остаток по Начислено равен нулю.
2. Создание отдельной обработки. Можно разработать внешнюю обработку или новое регламентное задание, которое будет запускаться периодически, находить такие некорректные "зависшие" остатки в регистре Бонусные баллы и автоматически создавать корректирующие записи для их закрытия.

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