Команда Manzana Platform рада представить обновления в рамках релиза 2026.003

Основные модификации Manzana Loyalty Online

Купон с коэффициентом списания баллов

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

Например, сценарий «Введи промокод и получи скидку в 2 раза больше при оплате баллами» — клиент списывает 100 баллов, а скидка составляет 200 рублей. Это создаёт у покупателя ощущение повышенной ценности накопленных баллов и мотивирует их тратить.

Механика поддерживает как общий промокод для всех участников, так и уникальные именные купоны с ограниченным числом применений. Подробнее — в документации.

Подробнее  в документации.

Суточный лимит перевода обычных и статусных бонусов

Раньше при переводе баллов между участниками программы лояльности действовал единый суточный лимит — без разделения по типу баллов. Это затрудняло гибкую настройку акций и контроль фрода.

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

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

Подробнее с описанием настроек можно ознакомиться  в документации.

История согласий на коммуникацию

В карточке контакта появилась вкладка «История согласия на рассылку» — в ней отображается полный лог изменений согласий на коммуникацию по SMS и Email.

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

Подробнее с описанием метода и настройки можно ознакомиться в документации.

Документация по электронным подарочным сертификатам

На портал документации добавлено описание нового функционала «Электронные подарочные карты».

Основные модификации Manzana Campaign

Подстановка значений в метапеременные при тестировании рассылок

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

Подробнее о функционале можно узнать из документации.

Фильтры "Тип механики ПП" и "Дней после перехода на статус"

В сегментатор Manzana Campaign добавлены два новых фильтра.

«Тип механики персонального предложения» — позволяет разделить аудиторию по виду рассчитанного персонального предложения. Например, одной части клиентов предлагается повышенный кешбэк на определённые товары, другой — скидка на категорию. Фильтр помогает отправить каждой группе свой шаблон сообщения.

«Дней после перехода на статус» — позволяет отбирать клиентов по числу дней с момента достижения нового уровня в программе лояльности. Удобно для приветственных сообщений новым участникам статуса или напоминаний о привилегиях.

Подробное описание новых фильтров находится по ссылке.

Технические модификации Мanzana Loyalty Online

1. Добавлено новое поле для настройки фильтрации контекстов при чтении данных синхронизации, включая возможность учета изменений с контекстом "без синхры" (0xFFFF). Доработана логика формирования запросов синхронизации для обеспечения точечного чтения данных в соответствии с указанными контекстами, что повысило гибкость и точность работы синхронизации (SQL часть #378347).
2. Выполнена оптимизация плана запроса процедуры processing.p_parse_request, что позволило снизить нагрузку на ЦПУ и нормализовать время выполнения транзакций, устранив повышенные тайминги. Работа была направлена на повышение стабильности и производительности базы данных (#376980).
3. Выполнена рекомпиляция процедуры p_charge_rule_find, что нормализовало её время выполнения и временно устранило проблему с деградацией плана запроса (#374657).
4. Оптимизирована обработка параметров с использованием дополнительной фильтрации по Pos_id, что существенно ускорило выполнение запроса и повысило производительность системы. Это позволило сократить время отклика при работе с данными чеков, обеспечив более эффективную работу сервиса (#374449).
5. Доработана процедура получения данных для снижения нагрузки на память и уменьшения времени выполнения транзакций, что улучшило стабильность работы сервиса и предотвратило тайм-ауты в кассовом оборудовании. Реализованы оптимизации и проведено тестирование для повышения производительности и надежности системы (#373082).
6. Реализована оптимизация процедуры p_bonus_disposal_return, что позволило устранить взаимоблокировки и нормализовать среднее время выполнения запросов, повысив стабильность работы сервера mo20_dbproc01. Проведён анализ и корректировка плана запроса для улучшения производительности (#367146).
7. Реализована деперсонализация данных с добавлением новых методов, с условиями выполнения аналогично текущим методам, но работающих с ContactExternalId вместо ContactIntId. В качестве входного параметра добавлен Еxternalid контакта, в ответе, где возвращается интовый идентификатор контакта, также возвращается ContactExternalId (#290547).
8. Реализовано корректное формирование и передача тегов комплектов в данных чека с учётом агрегирования позиций по фактическому количеству товара. Обеспечен переход на передачу номера позиции как текста и корректная обработка количества в .NET-сервисах для соответствия бизнес-требованиям (NET часть #358210).
9. Добавлена системная настройка Loyalty.Processing.Answer.BonusDetailAsAttribute.ReturnJson, позволяющая включать возврат расширенных атрибутов детализации начислений и списаний в формате JSON для удобства анализа данных (#357269).
10. Добавлено формирование нового типа тегов в ответах POS NG, которые содержат списки применимых правил по результатам фильтрации, что снижает нагрузку на MS SQL и упрощает обработку на стороне POS MS. Реализована передача итогового списка правил через gRPC-контракт, упразднена устаревшая логика обработки исключений и XML-тегов, обеспечивая тем самым корректную калькуляцию и позиционную детализацию применения правил (#354442).
11.  Реализована новая интеграция между MS POS и MS SQL, при которой данные по комплектам и фильтрам передаются в табличных типах вместо XML, что улучшило производительность и упростило передачу данных. Внедрена доработка процедуры обработки запросов и добавлено соответствующее логирование для контроля операции (#354440).
12. Реализован перевод мониторинга синхронизации данных между dbui и нодами на систему Zabbix с формированием и отправкой алертов на основе анализа расхождений в данных. Добавлены механизмы учета динамики изменений, настройки порогов алертов и автоматизированного создания задач поддержки с различными приоритетами в зависимости от степени критичности выявленных расхождений (#338768).
13. Реализована оптимизация внутреннего интеграционного взаимодействия в POS Service путем перехода препроцессинга на протокол gRPC, что повысило эффективность передачи данных. Для работы с новым протоколом была внедрена поддержка protobuf-моделей и обновлены настройки партнерских сервисов (#323485).
14. Реализована система отслеживания изменений данных через SQL-триггеры с хранением и секционированием изменений для обеспечения инкрементального чтения и эффективной очистки данных. Внедрены механизмы фиксации позиции чтения, фильтрации изменений по контексту и автоматизированной генерации SQL-запросов для потребителей, что повышает стабильность и масштабируемость системы (#315476).
15. Добавлены два дашборда в Grafana для мониторинга ошибок с кодами 4xx и 5xx по методам ODATA-адаптера, что позволило отслеживать количество ошибок в разрезе сервисных ручек и улучшить контроль за стабильностью работы сервиса. Предусмотрена возможность фильтрации и сортировки данных, а также хранение информации минимум за 7 дней (#303817).
16. Добавлена очистка временных таблиц сразу после их использования в соответствующих процедурах для повышения эффективности обработки данных и оптимизации производительности системы. Это позволяет снизить нагрузку на базу данных и улучшить стабильность работы сервиса. (#298230)
17. Добавлена включающая связь между кампанией и маркетинговым списком в сущности кампании для возможности корректной фильтрации по аналогии с исключающей связью. Добавлено представление в UI. Модифицирована логика фильтрации в методе GET Campaign/GetAllByContact (#276320).
18. В карточке Кампании в UI изменилось наименование значения для метода расчета чека и позиции для дисконтных правил, с "Суммы" на "Геометрическая сумма" (#255618).
19. Реализована возможность переключения логирования запросов ODATA-сервиса с хранения в базе данных MS SQL на запись в систему распределённой трассировки Jaeger c помощью системной настройки PrivateOffice.WebService.LogStorageEndpoint #362521.