Фильтры: основа хранения и логики данных

Фильтр — это универсальная единица хранения данных в CRM: через фильтры в договор, товар или услугу и карту клиента вводят и хранят все значимые параметры заказа. Какие фильтры показать и заполнить, система решает по контексту — статусу, городу и продукту, — поэтому одна и та же форма договора выглядит по-разному на разных этапах.

Разным компаниям и разным этапам заказа нужны разные поля: для чистки изделия — материал и площадь, для выезда мастера — адрес и удобная дата, для аренды — срок и залог. Если бы каждое такое поле зашивалось в код, любая настройка под отрасль требовала бы доработки системы. FriendClient вместо этого описывает поля фильтрами: администратор через простую веб-форму задаёт, какие данные, где и когда собирать. Это и делает CRM гибкой — её подгоняют под процесс, не переписывая.

При этом фильтры — не просто поля ввода. На них завязано появление полей, блокировка сохранения договора, запуск автоматических задач и расчёты стоимости. По сути это несущий слой данных, через который проходит вся бизнес-логика. Дальше — как фильтр устроен: с чем связан, что хранит, как настраивается и по каким правилам работает.

С чем связан

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

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

Какие данные хранит

  • тип данных — текст, число, дата, список и другие;
  • настройки обязательности;
  • условия отображения — статус, город, товар или услуга;
  • текущее значение в рамках конкретной сущности;
  • служебные значения — системные даты, пользователь.

Как это настраивается

Фильтр настраивается через веб-форму: задаются тип данных, обязательность и условия отображения. Условия отображения — ключевая часть: они определяют, на каком статусе, в каком городе и для какого продукта фильтр появится. Именно поэтому набор полей в форме договора меняется при смене статуса или города — показываются только фильтры, подходящие к текущему контексту.

Правила и ограничения

  • в составе договора обязательные фильтры должны быть заполнены, иначе данные не сохранятся;
  • при смене статуса и города набор фильтров может изменяться;
  • значения фильтров, неактуальных для нового статуса, удаляются;
  • чтобы сохранить данные на будущее, фильтр должен быть связан с картой клиента;
  • фильтры задач не существуют отдельно — они фиксируют изменения фильтров договора в процессе выполнения задачи.

Типичные сценарии

Оператор открывает договор на статусе первичной обработки — система показывает фильтры этого этапа, например «Количество комнат». После перехода на статус выезда появляются новые фильтры — «Адрес», «Удобный день», — а неактуальные пропадают.

Для услуги «Чистка ковра» настроен фильтр-список «Материал» — он появляется только у позиций этого продукта и участвует в расчёте стоимости.

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

Примеры настройки

  • Список «Материал ковра» — тип «список»; условие отображения — продукт «Чистка ковра»; обязательный; значение участвует в расчёте.
  • Число «Количество комнат» — тип «число»; условие отображения — статус первичной обработки; фильтр договора, обязателен по умолчанию.
  • Дата «Удобный день» — тип «дата»; условие отображения — статус «Назначение выезда»; используется автоматикой для даты задачи.
  • Фильтр для одного города — в условиях отображения оставлен единственный город; в договорах других городов он не появится.

Частые вопросы и подводные камни

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

Диагностика: фильтр ведёт себя не так, как ожидалось

Фильтр не появляется на договоре, хотя настроен. Проверьте условия отображения: статус договора, город и — для фильтра позиции — продукт должны совпадать с заданными. Если хоть одно условие не подходит, фильтр в форму не попадёт.

Значение фильтра исчезло после смены статуса. Это ожидаемое поведение: неактуальные для нового статуса значения удаляются. Чтобы значение сохранялось между заказами, его фильтр должен быть связан с картой клиента.