В процессе эксплуатации 1С:Управление торговлей 11 (УТ 11) у пользователей может возникнуть ситуация, когда остаток бонусных баллов у клиента оказывается значительно больше, чем должен быть по логике накоплений и списаний. Эта проблема особенно часто проявляется при использовании программ лояльности, предусматривающих начисление бонусных баллов с ограниченным сроком действия, например, бонусов за день рождения. Давайте подробно разберем, почему возникает такая некорректность в учете и как мы можем подойти к ее решению.
Мы выяснили, что основная причина проблемы кроется в некорректном формировании движений в регистре накопления "Бонусные баллы". Этот регистр использует два ключевых ресурса для учета бонусных баллов: Начислено и Ксписанию. Первый ресурс отражает общее количество начисленных баллов, а второй — количество баллов, которые по определенным условиям (например, истечение срока действия) должны быть списаны.
При начислении бонусных баллов со сроком действия, как в случае бонусов за день рождения, система должна корректно отразить не только факт начисления, но и будущую необходимость их списания. Однако, как показывает практика и примеры из форумной темы, типовой механизм может формировать движения таким образом, что это приводит к искажению остатков. Рассмотрим подробнее, что происходит:
Начислено, а вторая, предназначенная для учета баллов "к списанию", также формируется как приход, но по ресурсу Ксписанию.Ксписанию, который по своей сути должен служить счетчиком для уменьшения будущих остатков, начинает участвовать в расчете текущих остатков с видом "Приход", это приводит к двойному завышению бонусов. Более того, при определенных условиях, когда в запросах учитывается отрицательное значение этого ресурса, возникает ситуация "минус на минус", которая дает "плюс", еще больше искажая реальный остаток.Например, в одном из сообщений форума было указано, что запись Ксписанию на 5000 баллов, сформированная 28.01.2019, посчиталась в плюс, имея признак "Приход". Это является явной логической ошибкой, поскольку списания всегда должны формироваться с признаком "Расход" и корректно заполненными колонками.
Для понимания проблемы необходимо глубже рассмотреть структуру и логику работы регистра накопления "Бонусные баллы". Этот регистр предназначен для хранения информации о движении бонусных баллов клиентов.
Его основные ресурсы:
Начислено: Количество бонусных баллов, которые были начислены.Списано: Количество бонусных баллов, которые были списаны. (Хотя в обсуждаемой проблеме акцент делается на Начислено и Ксписанию, Списано также важно).Ксписанию: Количество бонусных баллов, предназначенных для списания по истечении срока действия.И измерения:
КлиентПрограммаЛояльностиДатаНачалаДействияДатаОкончанияДействияА также вид движения ВидДвиженияНакопления (Приход или Расход).
Ожидаемое поведение при начислении срочных бонусов:
Приход по ресурсу Начислено.Ксписанию. Логически, это также может быть Приход, но его учет в отчетах или при расчете доступных баллов должен быть особым – как "резерв", который будет уменьшен при списании или истечении срока. То есть, этот ресурс Ксписанию нужен для того, чтобы регламентное задание знало, какие бонусы и когда списать.Фактическое (проблемное) поведение:
Проблема возникает, когда система при расчете текущих доступных баллов некорректно интерпретирует движения по ресурсу Ксписанию. Вместо того чтобы использовать его как индикатор будущих списаний, он может быть ошибочно учтен как прямое увеличение доступных баллов. Особенно это проявляется, когда ресурс Ксписанию формируется как Приход, а затем в запросах отчетов или алгоритмах учета происходит некорректная операция, превращающая его в виртуальный "плюс", даже если логически он должен был бы быть вычтен.
Важно понимать, что любые фактические списания баллов должны генерировать движения с видом Расход по соответствующим ресурсам. Если документ начисления баллов создает приходы по Ксписанию, и при этом нет механизма, который бы адекватно эти приходы учитывал для последующего уменьшения остатков (через регламентное задание или другой механизм списания), или если эти приходы влияют на текущий доступный остаток, то это неизбежно приведет к завышению баллов.
Особую роль в работе с бонусными баллами, имеющими срок действия, играют регламентные задания. Часто пользователи ошибочно полагают, что если при начислении бонусов указан срок действия, то система автоматически позаботится об их списании по истечении этого срока. Однако это не всегда так.
В большинстве конфигураций 1С, включая УТ 11, для корректного списания просроченных бонусных баллов необходимо настроить и регулярно выполнять специальное правило списания бонусных баллов с типом "Регламентное списание". Это правило задает условия, при которых баллы будут считаться просроченными и подлежащими списанию.
Без такого правила регламентное задание не будет иметь указаний, какие баллы и когда нужно списывать. В результате, даже если в регистре накопления имеются записи, свидетельствующие о том, что баллы должны быть списаны (например, ресурс Ксписанию), без активного регламентного задания они так и останутся "висеть" на балансе клиента, искажая общую картину.
Для обеспечения точности учета, регламентные задания, отвечающие за списание просроченных баллов, должны запускаться ежедневно. Это гарантирует своевременную обработку всех баллов, срок действия которых истек за предыдущий день. Для контроля оборотов и своевременного выявления сгоревших бонусов можно использовать отчет по движению и списанию бонусных баллов.
Для того чтобы локализовать и устранить проблему перерасхода бонусных баллов, мы рекомендуем выполнить следующие шаги по диагностике и анализу:
Начнем с фундамента – с настроек вашей программы лояльности. Это первое, что нам нужно тщательно проверить.
Далее мы углубимся в движения, которые формируют документы начисления бонусных баллов. Для быстрого анализа движений и остатков с детализацией по документам можно использовать отчет по бонусным баллам с расшифровкой до регистратора.
ВидДвиженияНакопления (Приход или Расход) имеют эти записи.Начислено и Ксписанию.Мы ожидаем увидеть, что начисление формирует Приход по Начислено, а для баллов со сроком действия, возможно, также Приход по Ксписанию. Но если Ксписанию отражается как приход, это может быть источником проблемы.
Алгоритм отладки:
ОбработкаПроведения() модуля объекта документа).БонусныеБаллы.ВидДвижения, Начислено и Ксписанию.Пример кода, на который нам следует обратить внимание в отладчике:
// Примерный фрагмент кода формирования движений в модуле документа
Для Каждого СтрокаТабличнойЧасти Из Объект.ТабличнаяЧастьНачисления Цикл
// Движение по начислению баллов
Движение = Движения.БонусныеБаллы.Добавить();
Движение.Период = Объект.Дата;
Движение.Клиент = СтрокаТабличнойЧасти.Клиент;
Движение.ПрограммаЛояльности = СтрокаТабличнойЧасти.ПрограммаЛояльности;
Движение.Начислено = СтрокаТабличнойЧасти.КоличествоБаллов;
Движение.Списано = 0;
Движение.Ксписанию = 0; // Или другое значение, если нет срока действия
// Если баллы со сроком действия, формируем движение по Ксписанию
Если СтрокаТабличнойЧасти.ЕстьСрокДействия Тогда
// Возможно, здесь формируется отдельное движение или
// заполняется ресурс Ксписанию текущего движения.
// Если это отдельное движение, оно должно быть логически
// связано с целью списания, а не прибавления к доступному остатку.
ДвижениеКсписанию = Движения.БонусныеБаллы.Добавить();
ДвижениеКсписанию.Период = Объект.Дата;
ДвижениеКсписанию.Клиент = СтрокаТабличнойЧасти.Клиент;
ДвижениеКсписанию.ПрограммаЛояльности = СтрокаТабличнойЧасти.ПрограммаЛояльности;
// ... Заполнение других измерений
ДвижениеКсписанию.Начислено = 0;
ДвижениеКсписанию.Списано = 0;
ДвижениеКсписанию.Ксписанию = СтрокаТабличнойЧасти.КоличествоБаллов;
ДвижениеКсписанию.ВидДвижения = ВидДвиженияНакопления.Приход; // <= !!! Вот здесь может быть ошибка !!!
ДвижениеКсписанию.ДатаНачалаДействия = СтрокаТабличнойЧасти.ДатаНачалаДействия;
ДвижениеКсписанию.ДатаОкончанияДействия = СтрокаТабличнойЧасти.ДатаОкончанияДействия;
// Возможно, должно быть другое логическое поле или ресурс,
// или запрос отчета должен иначе обрабатывать Ксписанию.
КонецЕсли;
Движение.ВидДвижения = ВидДвиженияНакопления.Приход;
КонецЦикла;
Особое внимание уделите строке, где присваивается ДвижениеКсписанию.ВидДвижения = ВидДвиженияНакопления.Приход;. Если этот приход по Ксписанию затем учитывается как фактическое увеличение доступных баллов, то это и есть источник проблемы.
Если с движениями документа все кажется логичным (хотя бы с точки зрения того, что они формируются), переходим к регламентным заданиям.
Расход и учитывает все необходимые условия.Чтобы подтвердить проблему, выполните ручной пересчет остатка бонусных баллов для одного из клиентов, у которого наблюдается перерасход.
Иногда сами движения в регистре могут быть корректными с точки зрения логики сохранения данных, но запросы, которые используются для формирования отчетов (например, отчет "Остатки бонусных баллов" или данные в чеке), могут некорректно агрегировать эти данные.
Начислено и Ксписанию, а также ВидДвижения.
Например, запрос может ошибочно суммировать приходы по Ксписанию к общему доступному остатку, вместо того чтобы использовать их как информационный ресурс для регламентного списания или вычитать их из общей суммы при определенных условиях.
// Примерный запрос для получения остатков (может быть упрощен)
ВЫБРАТЬ
БонусныеБаллыОстатки.Клиент,
СУММА(БонусныеБаллыОстатки.НачисленоОстаток) КАК ДоступноНачислено,
СУММА(БонусныеБаллыОстатки.КсписаниюОстаток) КАК Ксписанию
ИЗ
РегистрНакопления.БонусныеБаллы.Остатки(&НаДату, ) КАК БонусныеБаллыОстатки
СГРУППИРОВАТЬ ПО
БонусныеБаллыОстатки.Клиент
// Здесь может быть проблема, если КсписаниюОстаток учитывается
// как положительный актив, вместо того чтобы быть маркером
// для уменьшения или коррекции доступного остатка.
После тщательной диагностики, мы можем определить наиболее подходящий путь решения. Важно понимать, что решение может быть комплексным и зависеть от конкретной версии конфигурации и ваших доработок.
Это самый простой и первый шаг, который мы должны предпринять, если еще не сделали этого. Убедитесь, что в вашей системе настроено и активно правило "Регламентное списание" для бонусных баллов. Мы должны задать условия, по которым баллы считаются просроченными, и убедиться, что соответствующее регламентное задание запускается ежедневно. Если регламентное задание настроено, но не работает, выясните причину сбоев (например, ошибки в коде, нехватка прав, проблемы с сервером).
Рассмотрим шаги по настройке (общие для УТ 11):
Если проблема вызвана некорректным формированием движений в документе начисления бонусных баллов (как это было описано в ходе диагностики, когда Ксписанию формируется как Приход и это приводит к завышению), то наиболее эффективным решением может быть доработка кода модуля объекта документа "Начисление бонусных баллов".
Наша задача: изменить логику формирования движений по регистру "Бонусные баллы" таким образом, чтобы ресурс Ксписанию либо не влиял на текущий доступный остаток при прямом запросе, либо чтобы его движения были более однозначными.
Возможные варианты доработки:
ВидДвиженияНакопления: Если ресурс Ксписанию ошибочно формируется как Приход и при этом учитывается в общей сумме доступных баллов, возможно, необходимо пересмотреть этот подход. В некоторых случаях, логичнее было бы, чтобы движения по Ксписанию были своего рода "отрицательным приходом" или чтобы они формировались только регламентным заданием. Однако, в типовых регистрах 1С такой гибкости нет, и Ксписанию обычно является положительным приходом, который затем уменьшается регламентным заданием. Проблема, скорее, в том, как этот Приход по Ксписанию интерпретируется в отчетах до момента фактического списания.Ксписанию - это действительно "к списанию"), но отчеты показывают неверные данные, то проблема в запросах. Нам нужно будет скорректировать запросы отчетов, чтобы они правильно учитывали ресурс Ксписанию, возможно, вычитая его из общей суммы или учитывая только те баллы, которые не относятся к "к списанию" на определенную дату.Важно: Любые изменения в типовой конфигурации требуют тщательного тестирования и желательно выполнять их на нерабочей копии базы данных. При обновлении конфигурации эти изменения могут быть утеряны или потребуют повторной адаптации.
После внесения изменений в настройки программ лояльности или в код, влияющий на расчет бонусных баллов, может потребоваться перепроведение документов за период, в котором были обнаружены некорректные начисления. Это позволит системе пересчитать движения по регистру "Бонусные баллы" в соответствии с новой логикой.
В особо запущенных случаях, когда перепроведение не помогает или невозможно, может потребоваться ручная корректировка данных в регистре "Бонусные баллы" или использование специальных обработок для исправления остатков. Это крайняя мера, которую мы должны применять с большой осторожностью и только после полного понимания причин и последствий.
После любых изменений, мы должны провести всестороннее тестирование. Создайте тестовые заказы и сценарии с различными условиями: начисление обычных бонусов, начисление срочных бонусов, оплата бонусами, истечение срока действия бонусов. Проверяйте остатки баллов в отчетах и карточке клиента после каждого действия, чтобы убедиться, что система работает корректно и проблема "перерасхода" устранена.
Таким образом, проблема перерасхода бонусных баллов в 1С:УТ 11, особенно при использовании срочных бонусов, часто связана с некорректной настройкой правил списания, логическими ошибками в движениях регистров накопления или неправильной интерпретацией данных в отчетах. Для успешного решения требуется комплексный подход, включающий проверку настроек, анализ движений документов с возможной доработкой кода, а также регулярный контроль работы регламентных заданий. Только так мы сможем обеспечить точный и надежный учет бонусных баллов в вашей системе.