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

​
Что такое реестр настроек компании

Реестр настроек — это единый список из 116 параметров, заданный в коде и одинаковый для всех компаний. Каждый параметр описан двумя или тремя элементами: Для конкретной компании в базе хранятся только изменённые значения. Всё остальное берётся из реестра. Поэтому «настройки компании» — это всегда наложение: реестр снизу, сохранённые значения компании сверху.
Набор параметров реестра можно переопределить на уровне платформы целиком, но в текущей конфигурации никаких переопределений нет — работает список, описанный ниже.

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

Сохранённое значение — это отдельная запись «компания + ключ + значение». Пара «компания + ключ» уникальна: у одной компании не может быть двух значений одного параметра. Ключи, по которым записи нет, работают на значении по умолчанию. Пустое значение в записи равносильно её отсутствию — при чтении оно снова подменяется значением по умолчанию.

​
Состав реестра

Ниже — полный состав реестра по смысловым группам. Группировка нужна для чтения: в самом реестре это один плоский список.
Больше половины параметров сервер только хранит и отдаёт наружу — проверяет их интерфейс. Ниже в колонке «Назначение» отдельно отмечено там, где серверная логика параметр действительно читает, и там, где не читает вовсе.

​
Реквизиты и валюта

Название, адрес, валюта и язык — единственные настройки, которые заполняются автоматически при создании компании. Подробнее: «Создание компании и её адрес».

​
Признаки доступных сущностей

Все признаки выключены по умолчанию. Включаются они не вручную, а подключением платного модуля или интеграции: у каждого модуля есть свой список ключей реестра, и подключение выставляет их компании во «включено». При регистрации компании подключается стартовый набор модулей, и признаки выставляются тем же механизмом. Подробнее: «Создание компании и её адрес».

​
Инвентаризация

​
Доставки и интеграции

Поведение подтверждения доставки описано отдельно: «Услуги и доставка». В реестре также сохранились два устаревших ключа доставки (уведомление по SMS и уведомление через сторонний мессенджер) — они не читаются ни одним участком системы и наружу не отдаются.

​
Транзакции

​
Цвета статусов аренды

Все семь параметров — это HEX-коды подсветки статуса в интерфейсе; сервер их не читает.

​
Поведение аренды

Как эти настройки влияют на жизненный цикл, описано в «Аренда и статусы». Работа автоархива броней разобрана в «Онбординг, новости и статистика».

​
Штрафы, выдача и смены

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

​
Проценты менеджеров

При создании заявки с первых пяти значений снимается снимок в собственный набор процентов заявки; общие настройки затем работают как запасной вариант при расчёте начислений. Подробнее: «Зарплаты и субаренда сотрудников».

​
Метрики

​
Бонусы и налог

Как бонусы применяются на практике — в «Бонусы».

​
Клиенты и документы

Режим тарификации документов — единственное поле набора, которое компания видит, но не может изменить. Подробнее: «Пакеты, баланс и квоты подписи».

​
Раскладка карточки аренды

​
Доступ к значениям

Вся система обращается к настройкам через один ленивый объект: он создаётся при первом обращении, поэтому импорт модулей на старте приложения не лезет в базу.

​
Чтение настройки

  1. Ключ проверяется по реестру. Неизвестный ключ или испорченное описание — сразу ошибка, «тихого» пустого ответа не бывает.
  2. Хранилище отдаёт сохранённое значение компании.
  3. Если сохранённого значения нет, берётся значение по умолчанию и тут же записывается компании как её собственное.
Третий шаг — не кэш, а настоящая запись в базу. Первое чтение любого параметра фиксирует для компании текущее значение по умолчанию: последующее изменение значения по умолчанию на уровне платформы такую компанию уже не затронет.

​
Запись и массовое обновление

  • Запись одного значения: ключ обязан быть в реестре, иначе ошибка. Значение уходит в базу и сразу кладётся в кэш.
  • Массовое обновление: сначала проверяются все переданные ключи, и только потом идёт запись пачкой. Если хотя бы один ключ незнаком, не сохраняется ничего.
  • Перечень ключей: объект умеет отдать список всех известных настроек — на этом построены и админка, и прогрев кэша.

​
Вне контекста компании

Настройки читаются в контексте конкретной компании. Если контекст не установлен, то:
  • чтение возвращает значение по умолчанию из реестра;
  • запись молча ничего не делает — ошибки не будет.
Обычное переключение схемы компании, которым пользуются фоновые задачи и служебные команды, контекст компании для настроек не устанавливает: слой настроек в этот момент считает, что компании нет, и отдаёт значения по умолчанию. Именно на этом спотыкается фоновая архивация броней — она читает оба своих параметра из реестра, видит выключенный признак и завершается на первой же компании, так что признак, включённый компанией, до неё не доходит. Это же — самый частый источник жалоб «настройка не применилась».

​
Хранение и кэш

Читать настройки приходится буквально на каждом шаге бизнес-логики, поэтому хранилище агрессивно кэширует. Ключевые следствия:
  • Прогретая пачка живёт сутки; значения, записанные поштучно, ложатся в кэш с общим коротким сроком жизни (15 секунд), после чего перечитываются из базы.
  • Создание новой записи настройки кэш не сбрасывает (при создании кэш и так уже содержит актуальное значение) — сбрасывает только изменение существующей.
  • Удаление записи кэш не сбрасывает вообще.
  • Массовое сохранение делает ровно один сброс на всю пачку, а не по сбросу на каждый ключ.
  • Кэш разложен по компаниям и по схемам: значения одной компании невозможно прочитать в контексте другой, но и вычистить их можно только из той же схемы, в которой они были записаны.

​
Единая точка API

Чтение и обновление всего набора настроек идёт через одну точку.

​
Что отдаётся

Ответ строится как значения по умолчанию из реестра, перекрытые сохранёнными значениями компании. Читается напрямую из базы, минуя кэш, — страница настроек всегда показывает актуальную картину, даже если у других процессов в кэше ещё старые значения. Схема ответа повторяет реестр за вычетом девяти служебных ключей, которые наружу не выходят и меняются только платформой:
  • буфер между арендами;
  • периодичность инвентаризации;
  • первоначальный взнос в графике;
  • тип фильтрации по датам;
  • автоучёт дней недели;
  • процент за сбор;
  • секрет банковского разбора выписок;
  • два устаревших ключа доставки.
Эти параметры продолжают работать: система читает их из реестра или из значений, выставленных платформой. Просто изменить их из интерфейса компании нельзя.
Только для чтения отдаются:
  • дополнительные поля справочников — меняются отдельной точкой;
  • режим тарификации документов — назначается платформой.

​
Кто что может

Изменение требует роли владельца компании, чтение — роли сотрудника или субарендодателя. Владелец читает набор потому, что при создании компании получает обе роли сразу; отдельно выданная роль владельца без роли сотрудника права на чтение не даёт.

​
Что происходит при сохранении

  1. Значения проверяются по схеме. Отрицательный срок аренды по умолчанию запрещён.
  2. Дополнительные поля из набора исключаются — их общий набор этой точкой не меняется.
  3. Остальные значения уходят в хранилище одной пачкой: запись, сброс и прогрев кэша компании.
При сохранении каждое «пустое» значение записывается как пустая строка, а не как ложь, ноль или пустой список. Выключенный флаг, нулевой процент, нулевая длительность и пустой список в базе выглядят одинаково — как пустое значение.На чтении это скрыто: числовые, дробные и временные поля подставляют вместо пустого значения ноль, а флаги читаются как «выключено». Но любой код и любая выгрузка, которые сравнивают сохранённое значение напрямую с «ложью» или «нулём» либо ожидают именно длительность, такую запись не найдут.
Частичное сохранение меняет только переданные параметры. Полное сохранение подставляет в непереданные поля значения по умолчанию из схемы API, а у семи полей они отличаются от реестра — см. раздел с подводными камнями.

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

Реестр — не справочный список, а рабочая развилка для значительной части бизнес-логики. Примеры прямых потребителей:
  • Подбор инвентаря. Приоритет подбора определяет порядок выборки единиц при автоматическом наполнении аренды и при добавлении продукта или комплекта.
  • Проверка занятости. Буфер между арендами продлевает занятость единицы после окончания предыдущей аренды на заданное число минут; на границе «конец новой аренды — начало следующей» буфер не применяется.
  • Просроченная инвентаризация. Периодичность инвентаризации задаёт, через сколько дней осмотр считается устаревшим (при пустом значении используется 7 дней).
  • Фильтрация списка аренд. Тип фильтрации по датам решает, по какой границе периода — начало, окончание или комбинированно — отбираются аренды; любое незнакомое значение отключает фильтр по датам целиком.
  • Начисления сотрудникам. Проценты подставляются как запасное значение, когда у заявки нет собственного снимка процентов.
  • Расчёт срока. Автоучёт дней недели включает пересчёт расписания аренды по рабочим дням.
  • Бонусы. Фиксированное начисление создаёт приветственную бонусную операцию при заведении бонусного счёта, процент начисления работает, если у клиента нет уровня лояльности, а лимит списания ограничивает долю аренды, оплачиваемую бонусами.
Практическое правило при разборе инцидента: сначала проверьте, в контексте какой компании выполнялся код, потом — есть ли у компании сохранённое значение, и только потом — значение по умолчанию из реестра.

​
Подводные камни

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

​
Менее заметные особенности

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

​
Уточнения

  • Незнакомое значение типа фильтрации по датам не просто игнорируется — оно полностью отключает отбор аренд по границам периода.
  • Название и адрес организации по умолчанию — латинские заглушки, а не пустые строки; отдельные участки системы специально проверяют заглушку названия, чтобы не подставить её в сообщения клиентам.
  • Валюта хранится либо символом, либо трёхбуквенным кодом: значение по умолчанию — символ, а при создании компании записывается код. При выводе сумм прописью значение приводится к коду через таблицу синонимов, потому что компании реально хранят там и то и другое.
  • Признак «начатый интервал считать полным» управляет только направлением округления количества штрафных интервалов (вверх вместо вниз) — к моменту фактического приёма инвентаря он отношения не имеет.
  • Фоновая архивация касается не завершённых аренд, а броней: в архив уходят брони, до начала которых осталось меньше заданной отсрочки, и все уже просроченные.
  • Бонусные значения по умолчанию именно в реестре — нулевой процент начисления, нулевое фиксированное начисление и лимит списания 100 %; другие цифры, которые встречаются в описании бонусной программы, приходят не из реестра, а из уровня лояльности клиента.
  • Дробный процент начисления бонусов из настроек компании обрезается до целого числа, поэтому значение вроде 2,5 % работает как 2 %; процент из уровня лояльности используется как есть.
  • Ответ единой точки собирается напрямую из базы, минуя кэш, поэтому страница настроек может показывать значение, которое остальные процессы ещё не подхватили.
  • Текстовые параметры реестра помечены не типом «текст», а вспомогательной функцией форматирования из стандартной библиотеки; распознавание типа в админке выживает только за счёт запасной ветки, а цветовые параметры распознаются по виду значения по умолчанию (решётка и 4 или 7 символов), а не по типу.

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

Глоссарий: Реестр настроек компании

Полный перечень полей и параметров реестра с их значениями по умолчанию.

Настройки компании

Обзорная страница модуля: из чего складываются настройки компании.

Хранение и кэш настроек

Как значение настройки попадает в базу, кэшируется по компаниям и почему его изменение сбрасывает кэш целиком.

Дополнительные поля

Собственные поля компании для клиентов, инвентаря, аренд и других справочников.

Переименование сущностей

Как компания меняет названия разделов и статусов под свою нишу, включая формы слова.

Настройки таблиц

Сохранённый состав, порядок и ширина колонок отдельно по каждой таблице компании.

Промо-баннеры

Показ рекламных и информационных баннеров внутри системы и отметка о просмотре.

Сквозная автонумерация

Общий счётчик компании для номеров клиентов, артикулов единиц и номеров документов.

Настройки в админ-панели

Служебный экран платформы для правки настроек компании и сброса значений к умолчанию.