> ## 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/company-billing/onboarding-news-stats-glossary). ## Что покрывает эта страница Здесь собраны вспомогательные части модуля компаний и биллинга, которые не относятся напрямую к жизненному циклу подписки и платежей, но работают в тех же общих таблицах платформы и обслуживают все компании сразу: * отметки о пройденных шагах онбординга компании; * системные новости с форматированным содержимым и вложенными изображениями; * снимки статистики по каждой компании (метрики бизнеса и размер базы данных); * планировщик пени по заявкам на аренду (общесистемная запись-таймер); * две фоновые задачи-помощника: архивация просроченных броней и отправка писем. Все перечисленные сущности хранятся в общих таблицах и относятся к учёту компаний в целом. Данные самих заявок, инвентаря и продаж лежат в отдельной схеме базы данных для каждой компании — задача архивации обращается к ним, устанавливая контекст нужной компании; снимок статистики описывает показатели каждой компании и хранится в общих таблицах. ## Онбординг компании ### Модель данных Шаг онбординга компании — это простая отметка «такая-то компания прошла такой-то шаг». | Поле | Тип | Назначение | | ---------------- | ---------- | ---------------------------------------------------- | | Идентификатор | число | Первичный ключ | | Компания | связь | Компания, к которой относится отметка | | Шаг | текст | Код пройденного шага (произвольная строка) | | Дата прохождения | дата/время | Проставляется автоматически в момент создания записи | Пара «компания + шаг» уникальна: один и тот же шаг нельзя отметить у одной компании дважды. Записи упорядочены по порядку добавления. ### Как это используется Онбординг доступен через личный кабинет компании и требует авторизации. * **Получение списка** возвращает только шаги текущей компании (компания определяется по контексту запроса, а не передаётся клиентом). Постраничная разбивка отключена — отдаётся весь список сразу. * **Отметка шага** создаёт новую запись; компания подставляется автоматически из контекста запроса, клиент передаёт только код шага. В ответе возвращаются код шага и дата прохождения. Набор кодов шагов не зафиксирован в модели — это свободный текст. Смысл конкретных кодов задаёт фронтенд, который и решает, какие шаги считать пройденными и как показывать прогресс. Повторная отправка уже отмеченного шага для той же компании нарушит требование уникальности пары «компания + шаг» и завершится ошибкой. Клиент должен либо не отправлять уже пройденные шаги, либо корректно обрабатывать такую ошибку. ## Новости ### Модель данных Новость — это системный анонс с форматированным содержимым и прикреплёнными изображениями. | Поле | Тип | Назначение | | --------------- | --------------------- | --------------------------------------------------------------------------- | | Заголовок | текст | Заголовок новости | | Содержимое | форматированный текст | HTML-контент; редактируется визуальным редактором в админке | | Изображения | связь (список) | Прикреплённые изображения (обобщённая связь с общим хранилищем изображений) | | Дата создания | дата/время | Момент создания (индексируется) | | Дата обновления | дата/время | Момент последнего изменения | Дата создания и дата обновления наследуются из базовой модели: первая проставляется один раз при создании, вторая обновляется при каждом сохранении. ### Как это используется Новости отдаются через публичный API под префиксом новостей и, в отличие от онбординга, не требуют авторизации. * **Список новостей** возвращает все новости, отсортированные от свежих к старым, с заранее подгруженными изображениями. * **Детали новости** возвращают одну новость по её идентификатору, также с подгруженными изображениями. В обоих случаях в ответ попадают идентификатор, заголовок, содержимое, список изображений и дата создания. Изображения доступны только для чтения — через этот API их нельзя добавить или изменить; наполнение новостей выполняется в админке. Изображения подгружаются заранее одним дополнительным запросом (а не по одному на каждую новость), поэтому список новостей с картинками не порождает лавину запросов к базе. Выбираются изображения из административного набора хранилища. ## Снимок статистики компании ### Модель данных Снимок статистики компании — это срез ключевых показателей одной компании на конкретный момент времени. Каждая запись — самостоятельный «фотоснимок»: новые данные не перезаписывают старые, а добавляются новой строкой, поэтому по накопленным записям можно смотреть динамику. Поля сгруппированы по смыслу: | Группа | Показатели | | ------------ | ----------------------------------------------------------------------------------------------------- | | Пользователи | Число сотрудников, число пользователей | | Тариф | Тип тарифа, период тарифа, категория компании | | Заявки | Дата последней заявки, всего заявок, в аренде, забронированных, завершённых, отменённых, просроченных | | Продажи | Число продаж | | Справочники | Число клиентов, услуг, точек проката, скидок, типов оплаты, категорий, каналов привлечения | | Инвентарь | Единиц инвентаря, наборов инвентаря, групп инвентаря | | Деньги | Число платежей, сумма платежей | | Служебные | Дата снимка, размер базы данных | Особенности отдельных полей: * **Дата снимка** индексируется и задаётся вручную при создании записи (а не автоматически) — это позволяет привязывать снимок к нужному расчётному моменту. * **Тип тарифа, период тарифа, категория и дата последней заявки** могут отсутствовать (например, у компании без активного тарифа или без единой заявки). * **Сумма платежей и размер базы данных** хранятся с точностью до двух знаков и по умолчанию равны нулю. Показатели заявок, инвентаря, продаж и справочников относятся к данным конкретной компании (доступны через изоляцию данных), а сама запись снимка хранится в общих таблицах рядом с остальными записями статистики. Размер базы данных отражает объём данных этой компании. Снимок — это сводка «сколько всего на момент X», а не журнал операций. Чтобы понять, что изменилось между двумя датами, нужно сравнить два снимка; сама запись изменения не хранит. ## Планировщик пени по заявке Планировщик пени по заявке — это общесистемная запись-таймер в общих таблицах, по которой периодически начисляется пеня по конкретной заявке на аренду. | Поле | Тип | Назначение | | ---------------- | ---------- | ---------------------------------------------------------------- | | Компания | связь | Компания, к которой относится начисление (может быть незаданной) | | Индекс | число | Порядковый номер правила пени в рамках заявки | | ID заявки | число | «Сырой» идентификатор заявки в данных компании | | Время начисления | дата/время | Момент, с которого начинается начисление | | Последний запуск | дата/время | Когда начисление сработало в последний раз | | Интервал | интервал | Период повтора (по умолчанию — один час) | | Включено | флаг | Активно ли начисление (по умолчанию выключено) | Тройка «компания + индекс + ID заявки» уникальна: у одной заявки может быть несколько правил пени, различаемых по индексу. Идентификатор заявки хранится как обычное число, а не как связь с таблицей заявок — потому что планировщик находится в общих таблицах, а сами заявки лежат в отдельной схеме базы данных своей компании. Поэтому запись всегда рассматривается в связке с компанией, в данных которой и содержится заявка с этим номером. Механика начисления пени (когда создаются записи, как срабатывает периодический запуск, как выполняется автоначисление и центральный пересчёт) подробно описана в отдельной странице. Подробнее: [«Депозиты и штрафы»](/ru/logic/rent/deposits-penalties). ## Задача архивации просроченных броней Фоновая задача проходит по всем компаниям и для каждой помечает удалёнными забронированные заявки, у которых начало аренды уже близко. Как это работает для каждой компании: 1. Задача устанавливает контекст компании на компанию и читает её настройки. 2. Если автоархивация в настройках выключена — обработка прекращается. 3. Если длительность буфера в настройках задана некорректно (не является интервалом времени) — обработка прекращается. 4. Иначе выбираются все заявки в статусе «забронирована», у которых начало аренды раньше, чем «текущий момент плюс буфер», и которые ещё не удалены; все они помечаются удалёнными. Идея: бронь, до старта которой осталось меньше буферного времени и которая так и не перешла в аренду, автоматически убирается из активных, чтобы не занимать инвентарь. Проверки «автоархивация выключена» и «буфер задан некорректно» прекращают работу задачи целиком, а не пропускают только текущую компанию. Из-за того, что настройки читаются в контексте компании каждой компании по очереди, компания, у которой автоархивация выключена или буфер настроен неверно, останавливает обработку всех компаний, идущих следом за ней в этом запуске. Это заметно, когда часть компаний архивируется, а часть — нет, в зависимости от порядка перебора. ## Задача отправки письма Простая фоновая задача отправки электронного письма списку получателей. Принимает тему, текст письма, список адресатов и необязательный HTML-вариант содержимого; отправитель берётся из системных настроек почты. Задача отправляет письмо без подавления ошибок: если почтовый сервер недоступен или отправка не удалась, задача завершится с ошибкой (а не молча проглотит её). Используется, в частности, при сбросе пароля. Поскольку ошибки не подавляются, сбой отправки виден в логах и попадает в стандартный механизм повторов и мониторинга фоновых задач — письмо не «теряется тихо». ## Связанные страницы Полный перечень полей шагов онбординга, новостей, снимков статистики и планировщика пени. Вернуться к обзору всего модуля компаний, подписок и платежей. Модель компании и её домены, генерация новой компании с дефолтными данными и регистрация владельца. Счета и их позиции, расчёт суммы, инициация оплаты и обработка вебхуков платёжного шлюза. Сохранённые платёжные карты компании и их привязка к автоматическим списаниям. Интеграция с платёжным шлюзом (подпись, инициация платежа, возвраты) и legacy-клиент. Лимиты плана по ресурсам, их цены по периодам и пересчёт фактического потребления.