Skip to main content
Полный перечень полей — в глоссарии.

​
Что покрывает эта страница

Здесь собраны вспомогательные части модуля компаний и биллинга, которые не относятся напрямую к жизненному циклу подписки и платежей, но работают в тех же общих таблицах платформы и обслуживают все компании сразу:
  • отметки о пройденных шагах онбординга компании;
  • системные новости с форматированным содержимым и вложенными изображениями;
  • снимки статистики по каждой компании (метрики бизнеса и размер базы данных);
  • планировщик пени по заявкам на аренду (общесистемная запись-таймер);
  • две фоновые задачи-помощника: архивация просроченных броней и отправка писем.
Все перечисленные сущности хранятся в общих таблицах и относятся к учёту компаний в целом. Данные самих заявок, инвентаря и продаж лежат в отдельной схеме базы данных для каждой компании — задача архивации обращается к ним, устанавливая контекст нужной компании; снимок статистики описывает показатели каждой компании и хранится в общих таблицах.

​
Онбординг компании

​
Модель данных

Шаг онбординга компании — это простая отметка «такая-то компания прошла такой-то шаг». Пара «компания + шаг» уникальна: один и тот же шаг нельзя отметить у одной компании дважды. Записи упорядочены по порядку добавления.

​
Как это используется

Онбординг доступен через личный кабинет компании и требует авторизации.
  • Получение списка возвращает только шаги текущей компании (компания определяется по контексту запроса, а не передаётся клиентом). Постраничная разбивка отключена — отдаётся весь список сразу.
  • Отметка шага создаёт новую запись; компания подставляется автоматически из контекста запроса, клиент передаёт только код шага. В ответе возвращаются код шага и дата прохождения.
Набор кодов шагов не зафиксирован в модели — это свободный текст. Смысл конкретных кодов задаёт фронтенд, который и решает, какие шаги считать пройденными и как показывать прогресс.
Повторная отправка уже отмеченного шага для той же компании нарушит требование уникальности пары «компания + шаг» и завершится ошибкой. Клиент должен либо не отправлять уже пройденные шаги, либо корректно обрабатывать такую ошибку.

​
Новости

​
Модель данных

Новость — это системный анонс с форматированным содержимым и прикреплёнными изображениями. Дата создания и дата обновления наследуются из базовой модели: первая проставляется один раз при создании, вторая обновляется при каждом сохранении.

​
Как это используется

Новости отдаются через публичный API под префиксом новостей и, в отличие от онбординга, не требуют авторизации.
  • Список новостей возвращает все новости, отсортированные от свежих к старым, с заранее подгруженными изображениями.
  • Детали новости возвращают одну новость по её идентификатору, также с подгруженными изображениями.
В обоих случаях в ответ попадают идентификатор, заголовок, содержимое, список изображений и дата создания. Изображения доступны только для чтения — через этот API их нельзя добавить или изменить; наполнение новостей выполняется в админке.
Изображения подгружаются заранее одним дополнительным запросом (а не по одному на каждую новость), поэтому список новостей с картинками не порождает лавину запросов к базе. Выбираются изображения из административного набора хранилища.

​
Снимок статистики компании

​
Модель данных

Снимок статистики компании — это срез ключевых показателей одной компании на конкретный момент времени. Каждая запись — самостоятельный «фотоснимок»: новые данные не перезаписывают старые, а добавляются новой строкой, поэтому по накопленным записям можно смотреть динамику. Поля сгруппированы по смыслу: Особенности отдельных полей:
  • Дата снимка индексируется и задаётся вручную при создании записи (а не автоматически) — это позволяет привязывать снимок к нужному расчётному моменту.
  • Тип тарифа, период тарифа, категория и дата последней заявки могут отсутствовать (например, у компании без активного тарифа или без единой заявки).
  • Сумма платежей и размер базы данных хранятся с точностью до двух знаков и по умолчанию равны нулю.
Показатели заявок, инвентаря, продаж и справочников относятся к данным конкретной компании (доступны через изоляцию данных), а сама запись снимка хранится в общих таблицах рядом с остальными записями статистики. Размер базы данных отражает объём данных этой компании.
Снимок — это сводка «сколько всего на момент X», а не журнал операций. Чтобы понять, что изменилось между двумя датами, нужно сравнить два снимка; сама запись изменения не хранит.

​
Планировщик пени по заявке

Планировщик пени по заявке — это общесистемная запись-таймер в общих таблицах, по которой периодически начисляется пеня по конкретной заявке на аренду. Тройка «компания + индекс + ID заявки» уникальна: у одной заявки может быть несколько правил пени, различаемых по индексу.
Идентификатор заявки хранится как обычное число, а не как связь с таблицей заявок — потому что планировщик находится в общих таблицах, а сами заявки лежат в отдельной схеме базы данных своей компании. Поэтому запись всегда рассматривается в связке с компанией, в данных которой и содержится заявка с этим номером.
Механика начисления пени (когда создаются записи, как срабатывает периодический запуск, как выполняется автоначисление и центральный пересчёт) подробно описана в отдельной странице. Подробнее: «Депозиты и штрафы».

​
Задача архивации просроченных броней

Фоновая задача проходит по всем компаниям и для каждой помечает удалёнными забронированные заявки, у которых начало аренды уже близко. Как это работает для каждой компании:
  1. Задача устанавливает контекст компании на компанию и читает её настройки.
  2. Если автоархивация в настройках выключена — обработка прекращается.
  3. Если длительность буфера в настройках задана некорректно (не является интервалом времени) — обработка прекращается.
  4. Иначе выбираются все заявки в статусе «забронирована», у которых начало аренды раньше, чем «текущий момент плюс буфер», и которые ещё не удалены; все они помечаются удалёнными.
Идея: бронь, до старта которой осталось меньше буферного времени и которая так и не перешла в аренду, автоматически убирается из активных, чтобы не занимать инвентарь.
Проверки «автоархивация выключена» и «буфер задан некорректно» прекращают работу задачи целиком, а не пропускают только текущую компанию. Из-за того, что настройки читаются в контексте компании каждой компании по очереди, компания, у которой автоархивация выключена или буфер настроен неверно, останавливает обработку всех компаний, идущих следом за ней в этом запуске. Это заметно, когда часть компаний архивируется, а часть — нет, в зависимости от порядка перебора.

​
Задача отправки письма

Простая фоновая задача отправки электронного письма списку получателей. Принимает тему, текст письма, список адресатов и необязательный HTML-вариант содержимого; отправитель берётся из системных настроек почты. Задача отправляет письмо без подавления ошибок: если почтовый сервер недоступен или отправка не удалась, задача завершится с ошибкой (а не молча проглотит её). Используется, в частности, при сбросе пароля.
Поскольку ошибки не подавляются, сбой отправки виден в логах и попадает в стандартный механизм повторов и мониторинга фоновых задач — письмо не «теряется тихо».

​
Связанные страницы

Глоссарий: Онбординг, новости и статистика

Полный перечень полей шагов онбординга, новостей, снимков статистики и планировщика пени.

Компании и биллинг (подписки, платежи)

Вернуться к обзору всего модуля компаний, подписок и платежей.

Создание компании и её адрес

Модель компании и её домены, генерация новой компании с дефолтными данными и регистрация владельца.

Инвойсы и платежи

Счета и их позиции, расчёт суммы, инициация оплаты и обработка вебхуков платёжного шлюза.

Карты и автосписания

Сохранённые платёжные карты компании и их привязка к автоматическим списаниям.

Платёжные шлюзы

Интеграция с платёжным шлюзом (подпись, инициация платежа, возвраты) и legacy-клиент.

Лимиты и тарификация

Лимиты плана по ресурсам, их цены по периодам и пересчёт фактического потребления.