Вы когда-нибудь сталкивались с ситуацией, когда при фильтрации сделок по статусам отображались… провальные сделки, несмотря на то, что в фильтре они исключены? Я — да, рассказываю дальше.

Что интересно, при проверке показывает:
— Cистема обновлена.
— Диагностика ошибок не выявляет.
— Интерфейс фильтра работает как положено.

Тем не менее, в итоговой выборке всё равно появлялись сделки со статусом «Сделка провалена». Проверил разные направления (воронки), но быстро понял, что ситуация повторяется.

Дальше выяснил, что у части сделок в базе данных был некорректно указан параметр STAGE_SEMANTIC_ID. Он не совпадал с фактическим статусом сделки. В интерфейсе все выглядело идеально, но фильтрация шла по «сырому» значению в базе. Именно это ломало результат.

Пришлось аккуратно обновить данные через SQL-запрос. Для проваленных сделок, например, подошел такой:

UPDATE b_crm_deal 
SET STAGE_SEMANTIC_ID=’F’ 
WHERE STAGE_ID IN (
  SELECT STATUS_ID 
  FROM b_crm_status 
  WHERE ENTITY_ID LIKE «%DEAL_STAGE%» AND SEMANTICS=’F’
) AND STAGE_SEMANTIC_ID=’P’;

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

Когда фильтры в CRM начинают вести себя странно, а по интерфейсу все чисто, то загляните глубже. Возможно, дело в несостыковках на уровне базы. Особенно если портал пережил миграции, интеграции или кастомные доработки.

Нужна помощь с диагностикой или разбором подобных «призраков» в Битрикс24? Пишите @gruzdevoleg, помогу найти источник.