> ## Documentation Index > Fetch the complete documentation index at: https://docs.yume.cloud/llms.txt > Use this file to discover all available pages before exploring further. # Уведомления, бонусы и воронка > Побочные эффекты сохранения аренды: уведомления клиенту в мессенджер при смене статуса, лиды воронки продаж, автоматическое начисление бонусов и повышение по «отметкам» лояльности, а также реферальные вознаграждения агентам. Полный перечень полей — в [глоссарии](/ru/logic/rent/triggers-glossary). Когда аренда меняет статус (переход из одного состояния жизненного цикла в другое) или просто пересохраняется, система не ограничивается записью в базу. В самом конце сохранения аренды срабатывает цепочка побочных эффектов: клиенту уходит уведомление в мессенджер, в отдел продаж создаются или переносятся лиды, клиенту начисляются бонусы за завершённую аренду, он повышается по «отметкам» лояльности, а реферальному агенту фиксируется вознаграждение. Эта страница описывает, что именно и в какой момент срабатывает, какие есть точки принятия решений и как это использовать. ## Общая картина Все автоматические эффекты запускаются в одной точке — сразу после того, как аренда сохранена в базе. Порядок такой: 1. пересчитывается график занятости инвентаря — **в том же запросе**, потому что от доступности зависит бронирование; 2. в очередь ставится **одна фоновая задача**, которая рассылает уведомления клиенту (сторона мессенджера) и создаёт либо переносит лиды в воронке продаж. Дополнительно, уже как реакция на факт сохранения, отдельно отрабатывают: * начисление бонусов клиенту (только для завершённой и полностью оплаченной аренды); * продвижение клиента по «отметкам» лояльности (только для завершённой аренды). Задача с уведомлениями и воронкой ставится в очередь **только после того, как изменения аренды успешно зафиксированы** в базе. Если сохранение откатилось, задача не поставится и «фантомных» уведомлений по несуществующему переходу не будет. Обратная сторона — уведомление и лид появляются с небольшой задержкой уже после ответа сервера. Раньше уведомления и воронка выполнялись прямо внутри сохранения аренды и их сбой гасился без следа. Теперь ошибка видна как упавшая фоновая задача — её можно найти и переиграть, — а на скорость самого запроса эти реакции больше не влияют. Сбой всё так же не откатывает сохранение аренды. Начисление бонусов остаётся исключением: если создание бонусной операции падает, ошибка по-прежнему гасится без записи в журнал, и бонус может молча не начислиться. ## Уведомления клиенту при смене статуса ### Когда формируется уведомление Подготовка уведомления происходит при каждом сохранении аренды, но реально что-то отправляется только если выполнены все условия: * **статус действительно изменился** — если новый статус совпадает с прежним, уведомление не готовится вообще; * аренда **не удалена**; * у аренды **есть клиент** (иначе слать некому — уведомление не готовится). Если условия выполнены, система собирает «контекст шаблона» — набор подстановок, из которых потом строится текст сообщения, и ставит фоновую задачу отправки. ### Что попадает в контекст сообщения | Поле | Что содержит | | --------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Менеджер | Имя и фамилия сотрудника, инициировавшего изменение (текущий пользователь запроса, а если его нет — тот, кто создал аренду) | | Имя клиента | Название/имя клиента аренды | | Телефон клиента | Номер клиента | | Номер аренды | Идентификатор аренды | | Сумма со скидкой | Итоговая сумма аренды к оплате | | Сумма скидки | Размер скидки | | Плановые и фактические даты | Начало и конец аренды по плану и по факту, отформатированные в часовом поясе Asia/Tashkent на русском | | Остаток бонусов | Текущий бонусный баланс клиента | | Позиции | Перечень групп инвентаря в аренде с количеством | Перечень позиций собирается только по «настоящим» позициям — те позиции, которые были заменены при обмене, в список не попадают. Если у группы больше одной единицы, рядом с названием указывается количество (например, «Палатка (3 шт.)»). ### Как выбираются сообщения к отправке Задача отправки работает в контексте конкретной компании и по её интеграции с мессенджером Wazzup: * если запрос выполняется вне контекста компании — задача сразу завершается, ничего не делая; * если у компании **нет подключения** к Wazzup или оно **неактивно** — рассылки не будет. Дальше подбираются триггеры сообщений: берутся только те, что настроены на переход **из прежнего статуса в новый** для сущности «аренда». Здесь есть важное правило по срочности: * если задаче передан конкретный триггер, отправляется именно он; * если конкретный триггер не задан (обычный путь при смене статуса), берутся **только мгновенные триггеры** — те, у которых задержка отправки не больше одной минуты. При автоматической смене статуса аренды отправляются только «мгновенные» уведомления (задержка до 1 минуты). Отложенные триггеры (например, «напомнить через сутки») в этот момент не запускаются — их запускает отдельный планировщик, передавая задаче конкретный триггер. Если ожидаемое уведомление не пришло сразу, но настроено с задержкой — это нормальное поведение. Подходящие триггеры перебираются в порядке их сортировки, и по каждому ставится отдельная задача отправки сообщения — с текстом триггера, идентификатором и ключами шаблона и собранным контекстом. ### Отдельный сценарий: уведомление о просрочке Для перехода аренды в статус «просрочка» есть выделенная задача. Она отличается от обычного пути: * на вход получает идентификатор аренды и конкретный триггер сообщения; * если аренда не найдена или у неё нет клиента — завершается без отправки; * переход статуса всегда трактуется как «в просрочку» (целевой статус жёстко зафиксирован); * менеджером считается создатель аренды, а если его нет — сотрудник из последнего действия по аренде; * собирает такой же контекст (без остатка бонусов) и вызывает общую отправку уже **с указанием конкретного триггера** — то есть здесь отправка не ограничена «мгновенными» триггерами. ## Лиды в воронке продаж При смене статуса аренда дёргает воронку продаж. Здесь описана только точка вызова со стороны аренды; вся механика триггеров этапов, создания и переноса лидов живёт на стороне продаж. Условия и поведение точки вызова: * если аренда удалена — ничего не происходит; * если у компании не подключена интеграция с воронкой — ничего не происходит; * если статус **не изменился** (пересохранение без перехода) — у уже существующих лидов этой аренды только обновляются сумма и клиент, новые лиды не создаются; * если статус **изменился** — по настроенным триггерам «источник заявки» лиды переносятся между этапами/воронками и при необходимости создаются новые (по одному на подходящий этап), после чего по каждому лиду выполняются триггеры его нового этапа. То есть аренда сама не «знает» правил воронки — она лишь сообщает, из какого статуса в какой перешла. Что при этом произойдёт с лидами, определяется настройками триггеров этапов. Подробнее про правила воронки: [«Триггеры этапов»](/ru/logic/sales/triggers). ## Бонусы: автоматическое начисление за завершённую аренду Как реакция на сохранение аренды бонусы начисляются клиенту автоматически, но при строгих условиях. Начисление происходит **только если одновременно**: * аренда не удалена; * у аренды есть клиент; * статус аренды — «завершена»; * статус оплаты — «оплачено». Если хоть одно условие не выполнено, начисления нет. ### Как считается сумма начисления Процент начисления берётся из персональной программы лояльности клиента (если она у него привязана), иначе — из процента начисления по умолчанию в настройках компании. Сумма к начислению = **итоговая сумма аренды со скидкой × процент ÷ 100**. Дальше система защищается от двойного и неверного начисления: * если по этой аренде клиент уже **списывал** бонусы — начисление за завершение не производится; * если начисление по этой аренде уже было и его сумма не совпадает с пересчитанной — сумма приводится к правильной; * если начисления ещё не было — создаётся новое. Начисление привязано к конкретной аренде, поэтому многократное пересохранение завершённой оплаченной аренды не «размножает» бонусы: повторный проход либо ничего не меняет, либо только выравнивает сумму. Полное описание жизненного цикла бонусов, включая приветственный бонус и значения в карточке аренды: [«Бонусы»](/ru/logic/clients-loyalty/bonuses). ## Бонусы: ручное списание на аренду Помимо автоматического начисления есть отдельные операции, которыми менеджер вручную применяет бонусы клиента к оплате конкретной аренды и отменяет их. ### Списание бонусов на аренду При списании: 1. проверяется, что у аренды выбран клиент (иначе — ошибка «не выбран клиент»); 2. находится или создаётся бонусный счёт клиента; 3. **если счёт создаётся впервые** и в настройках задан ненулевой приветственный бонус — на счёт зачисляется приветственная сумма; 4. вычисляется максимально допустимая сумма списания; 5. создаётся списание на эту сумму (бонусная транзакция с отрицательным знаком), привязанное к аренде; 6. запускается пересчёт дочерних сумм аренды. Максимально допустимая сумма списания — это **минимум из трёх величин**: | Ограничитель | Смысл | | ----------------- | -------------------------------------------------------------------- | | Остаток к оплате | Итоговая сумма со скидкой минус уже оплаченное | | Лимит по проценту | Итоговая сумма со скидкой × допустимый процент оплаты бонусами ÷ 100 | | Баланс бонусов | Сколько бонусов есть у клиента | Числовой пример. Итоговая сумма аренды — 100 000, уже оплачено — 30 000, допустимый процент оплаты бонусами — 50%, баланс бонусов клиента — 40 000. Тогда три ограничителя равны 70 000, 50 000 и 40 000, а списывается минимальный из них — **40 000**. Если бы баланс был 60 000, списалось бы 50 000 (упёрлись бы в лимит по проценту). Списание применяется без дополнительной проверки статуса аренды и без предпросмотра суммы: операция сразу создаёт транзакцию на вычисленный максимум и пересчитывает суммы. Отменить можно только целиком (см. ниже) — частичной корректировки списанной суммы нет. ### Отмена списания Отмена удаляет по аренде **все бонусные списания** (транзакции с отрицательной суммой) и запускает пересчёт дочерних сумм аренды. Приветственный или иной начисленный бонус (положительные транзакции) при этом не трогается — отменяется только то, что было списано на оплату. ## Продвижение клиента по «отметкам» лояльности Ещё один автоматический эффект сохранения — пересмотр «отметок» клиента (уровней/меток, привязанных к порогам по числу и сумме аренд). Он срабатывает **только для завершённой аренды** (и только если аренда не удалена и у неё есть клиент). Логика: 1. по клиенту считаются все его **завершённые активные** аренды — их количество и суммарная итоговая стоимость со скидкой; 2. подбираются все отметки, у которых задан порог по количеству аренд или по сумме, и чей порог уже достигнут клиентом (по количеству **или** по сумме); 3. эти отметки добавляются клиенту. Пороги проверяются по правилу «или»: достаточно набрать нужное количество аренд **либо** нужную суммарную сумму, чтобы получить отметку. Отметки только добавляются — этот механизм их не снимает. ## Реферальные вознаграждения агентам За конкретную аренду можно зафиксировать вознаграждение реферальному агенту. Здесь описан только API-контур со стороны модуля аренды; полное определение сущности «Реферальное вознаграждение по аренде» и её жизненный цикл — на отдельной странице. Доступные операции: | Операция | Что делает | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------- | | Список и добавление | Показывает вознаграждения по конкретной аренде и создаёт новое; из выборки скрыты вознаграждения по удалённым арендам | | Просмотр, изменение, удаление | Операции над одним вознаграждением; удалённые аренды также скрыты | | Отметка «Выплачено» | Переводит вознаграждение в статус «Выплачено», проставляя момент и автора изменения | Ключевые правила создания и изменения (проверяются при валидации): * новое вознаграждение всегда привязывается к аренде из адреса запроса; агент может быть не указан; * если аренда уже **завершена или отменена**, создавать/менять вознаграждение нельзя — **кроме** случая, когда у пользователя есть право работать с завершёнными арендами (или он суперпользователь компании); * текущий статус связанной аренды доступен в ответе только для чтения; * перевод в статус «Выплачено» фиксирует время и пользователя, отметившего выплату. Для всех операций нужны права на модель аренды и подключённая интеграция «аренда». Просмотр списка и карточки достаточно иметь при просто подключённой интеграции; для создания, изменения, удаления и отметки «Выплачено» интеграция должна быть ещё и активна (срок использования не истёк). Подробнее про сущность и её двойной учёт (по агентам и денежная строка аренды): [«Рефералы»](/ru/logic/clients-loyalty/referrals). ## Как это используется * Настройте триггеры сообщений в мессенджере на нужные переходы статусов — тогда клиент будет получать уведомления автоматически при смене статуса аренды. Для мгновенных сообщений держите задержку до одной минуты. * Держите у аренды заполненного клиента: без клиента не уйдут ни уведомления, ни автоматические бонусы, ни отметки лояльности. * Автоматическое начисление бонусов «за аренду» происходит только в момент, когда аренда становится одновременно завершённой и полностью оплаченной. Ручное списание бонусов на оплату — отдельная операция и делается заранее, до завершения. * Реферальные вознаграждения удобнее заводить до завершения/отмены аренды; после — потребуется специальное право. ## Особенности поведения * Приветственный бонус зачисляется только в момент первого создания бонусного счёта клиента при ручном списании; для уже существующего счёта приветственный бонус повторно не начисляется. * Отмена списания бонусов удаляет все списывающие транзакции по аренде, но не трогает положительные начисления — то есть возвращает списанное, но не убирает начисленный приветственный/бонус. * Автоматическое начисление бонусов за аренду происходит только когда статус одновременно «завершена» и оплата «оплачено»; если по аренде уже было ручное списание бонусов, автоматическое начисление за завершение пропускается. * Отметки лояльности только добавляются клиенту по достижении порога (по количеству или сумме завершённых активных аренд) и никогда не снимаются автоматически. * Реферальное вознаграждение нельзя создать или изменить по завершённой или отменённой аренде без права на работу с завершёнными арендами (или прав суперпользователя компании). * Для реферальных операций просмотр списка и карточки требует лишь подключённой интеграции «аренда», а создание, изменение, удаление и отметка «Выплачено» — активной (не истёкшей) интеграции. * В контекст уведомления и в перечень позиций попадают только «настоящие» позиции инвентаря; позиции, заменённые при обмене, из перечня исключаются. * Уведомление о просрочке вызывает общую отправку с конкретным триггером, поэтому на него ограничение «только мгновенные триггеры» не распространяется. * При пересохранении аренды без смены статуса лиды не создаются и не переносятся — у существующих лидов только обновляются сумма и клиент. * Уведомления и воронка выполняются одной фоновой задачей, которая ставится в очередь после успешной фиксации изменений аренды; её сбой виден как упавшая задача, а не теряется в логе. * Каждое сохранение аренды ставит свою задачу триггеров, поэтому сценарии, в которых аренда пересохраняется несколько раз за одну операцию (например, автопродление), могут приводить к повторным уведомлениям. ## Связанные страницы Определения всех терминов и полей этой страницы: уведомления, лиды, бонусы и реферальные вознаграждения. Обзорная страница модуля аренды со ссылками на все его разделы. Ядро сущности аренды, автомат статусов и статус оплаты, а также создание, редактирование, закрытие и архивация заявок. Действия по аренде: бронирование, сборка, выдача, приёмка, отмена и архив, а также отмена действия с восстановлением статуса. Строки инвентаря аренды и продажи, их тарифы и периоды, массовые операции и обмен позиций внутри заявки. Услуги в составе аренды (включая типы доставки) и доставки с привязкой к действиям аренды. Движок пересчёта итогов аренды: цены позиций и услуг, скидки, налоги, продление периода и суммарные поля заявки. Привязка депозитов и штрафов к аренде и позициям, плюс генерация штрафных задач. График платежей и автосписание, паузы аренды и рабочие/выходные дни, влияющие на длительность и суммы.