> ## 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. # Отслеживание изменений и оповещение > Перехват значимых изменений заказа аренды, пометка непогашенных пропусков компании обновлёнными и отложенная фоновая рассылка push-обновлений на телефоны клиентов после фиксации транзакции. Полный перечень полей — в [глоссарии](/ru/logic/wallet/change-dispatch-glossary). ## Что делает эта часть модуля Когда заказ аренды меняется, у клиента в Apple Wallet должна автоматически обновиться его карта заказа: новый статус, новые даты, актуальная сумма к оплате. Эта часть модуля отвечает за то, чтобы система вовремя «заметила» значимое изменение заказа, отметила соответствующие пропуска как обновлённые и разослала телефонам клиентов сигнал «пора скачать свежую версию карты». Автоматическая связка «отметка обновления + push» в этой части работает только для карт Apple Wallet. Карты Google Wallet в модуле тоже поддерживаются, но обновляются по другому пути и этим механизмом не затрагиваются. Механизм состоит из трёх звеньев: 1. **Перехват изменений заказа** — автоматический обработчик, который срабатывает при каждом сохранении заказа. 2. **Пометка пропуска обновлённым** — общая процедура, которая находит нужные карты, поднимает у них отметку времени изменения и ставит фоновые задачи на отправку push. 3. **Регистрация обработчика при старте** — подключение перехватчика к событиям заказа в момент запуска приложения. Отметка времени изменения на пропуске (поле «Обновлён») — это тот самый признак, по которому устройство Apple понимает, что карта устарела и её нужно перекачать. Push лишь «будит» телефон, а решение об обновлении устройство принимает, сверяя эту отметку. Поэтому поднять отметку времени так же важно, как и отправить push. ## Отслеживание изменений заказа При каждом сохранении заказа аренды автоматически вызывается обработчик изменения заказа. Он решает, нужно ли беспокоить карты клиента, по двум правилам: * **Создание заказа игнорируется.** Если заказ только что создан, обработчик сразу завершает работу. Пропуск для нового заказа выпускается в другом месте (при выдаче карты клиенту), а не по факту создания заказа. * **Фильтр по значимым полям.** Если сохранение указывает конкретный список изменённых полей, обработчик реагирует только тогда, когда этот список пересекается с набором «значимых полей заказа». Изменение любого другого поля (например, служебной пометки) карту не трогает. ### Значимые поля заказа Обновление карты запускают изменения именно тех полей, которые видны клиенту на лицевой стороне пропуска: | Что изменилось | Почему это важно для карты | | --------------------------------- | ------------------------------------- | | Статус заказа | Клиент видит текущее состояние аренды | | Статус оплаты | Отражает, оплачен ли заказ | | Плановая дата начала аренды | Даты проката на карте | | Плановая дата окончания аренды | Даты проката на карте | | Фактическая дата начала аренды | Фактические сроки | | Фактическая дата окончания аренды | Фактические сроки | | Точка выдачи | Где забрать технику | | Точка возврата | Куда вернуть технику | | Скидка по цене | Влияет на итоговую сумму | | Оплаченная сумма | Остаток к оплате на карте | Если изменилось хотя бы одно из этих полей — карта считается устаревшей и запускается процедура пометки пропуска обновлённым для типа «Заказ». Фильтр по значимым полям работает только тогда, когда сохранение заказа явно перечисляет изменённые поля. Если поля не перечислены (обычное полное сохранение заказа), фильтр пропускается и процедура пометки запускается при **любом** сохранении заказа. Лишний холостой прогон не вреден — если реальных изменений в картах нет, процедура тихо завершится, — но это значит, что нагрузка на этот механизм привязана к частоте сохранений заказов в целом, а не только к «значимым» правкам. ## Пометка пропуска обновлённым Это общая процедура, к которой обращается обработчик заказа (а также, при необходимости, другие места модуля). Она получает на вход тип пропуска (здесь — «Заказ») и идентификатор связанного объекта (здесь — идентификатор заказа) и выполняет следующие шаги. ### Шаг 1. Проверка контекста компании Процедура сначала убеждается, что известна текущая компания. Пропуска хранятся в общих (глобальных) таблицах, но привязаны к конкретной компании, поэтому без установленного контекста компании выбрать «свои» карты невозможно. Если контекст компании не определён — процедура молча завершается, ничего не делая. Обработчик заказа всегда работает уже внутри контекста конкретной компании (заказы принадлежат компании), поэтому в штатном потоке этот контекст присутствует. Проверка защищает от вызовов вне обычного веб-запроса. ### Шаг 2. Выбор непогашенных пропусков Процедура находит все пропуска, у которых одновременно совпадают: * **компания** — активная компания; * **тип пропуска** — «Заказ»; * **идентификатор связанного объекта** — идентификатор изменившегося заказа; * **признак аннулирования** — пропуск не аннулирован. Аннулированные карты в выборку не попадают: их обновлять бессмысленно. Из выборки берётся список серийных номеров найденных пропусков. На один объект (заказ) заводится ровно один пропуск, поэтому обычно в списке один серийный номер. Тем не менее логика рассчитана на несколько карт и рассылает push каждой найденной. Если для заказа не нашлось ни одного действующего пропуска (карту клиенту вообще не выпускали) — процедура завершается, не производя записи в базу и не создавая фоновых задач. ### Шаг 3. Подъём отметки времени изменения Для всех найденных пропусков одним групповым обновлением проставляется текущий момент времени в поле «Обновлён». Именно эта отметка сигнализирует устройству клиента, что его версия карты устарела. ### Шаг 4. Отложенная рассылка push Рассылка push-задач ставится не сразу, а «после успешного сохранения изменений в базу». Только когда изменения гарантированно зафиксированы, на каждый серийный номер ставится отдельная фоновая задача push-обновления пропуска. Push-задачи ставятся строго после фиксации изменений. Если операция сохранения по какой-то причине откатится, отметка времени не сохранится и push-и не уйдут — карты не окажутся в рассинхроне с базой. Это осознанная защита от «преждевременных» уведомлений. ## Фоновая доставка уведомления Каждое уведомление отправляется в фоне, отдельно по каждой карте. При сбое отправка повторяется автоматически — до трёх раз с паузой около 10 секунд. Если карта установлена сразу на нескольких телефонах, уведомление уходит на каждый из них. ## Подключение обработчика при старте Отслеживание изменений заказа включается автоматически при запуске системы — отдельной настройки для этого не требуется. ## Как это связано с остальным модулем Эта часть не выпускает карты и не формирует их содержимое — она лишь следит за изменениями заказа и запускает обновление уже выпущенных карт. Само содержимое собирается позже, когда телефон клиента приходит за свежей версией — см. [«Как телефон получает свежую карту»](/ru/logic/wallet/card-refresh). ## Связанные страницы Полный перечень значимых полей заказа, типов пропусков и параметров рассылки. Обзор раздела: какие бывают карты, как их получает клиент и как они обновляются. Сводный список известных подводных камней и ошибок по всему модулю. Какие сведения система хранит о выпущенной карте и о телефонах, подписанных на обновления. Ссылки, по которым клиент получает карту для Apple Wallet или Google Wallet. Что клиент видит на карте: поля, QR-код, фирменные цвета и логотип. Как формируется карта и ссылка сохранения для Google Wallet. Что происходит между телефоном клиента и системой, когда карта обновляется. Бесшумные уведомления, которые заставляют телефон перекачать карту.