Осенью 2024 года был анонсирован новый функциональный модуль при Битриксе24 CRM - BI Конструктор. BI конструктор позволяет создавать отчеты и дашборды прямо внутри среды CRM, объединяя данные из разных таблиц модели данных Битрикс24, и предназначен для удобного анализа бизнес-показателей без привлечения внешних систем. Доступно это новшество было на старших тарифных планах, но что он в себя включает и на что я хотел бы обратить внимание через частную задачку?

Здесь все очень просто: за кадром (речь про облако): БД CRM скорее всего на MySQL, может на PostgreSQL, но в BI вы работаете с реплицированными данными. Коллектор и обработчик ваших SQL - это Trino, а собственно сам BI - Apache Superset (или его "форк" от 4-ой версии). Зная это, несложно разобраться как сделать свой дашборд, пройдя путь: запрос ➡️ датасет ➡️графики ➡️ дашборд. И в этом материале я бы хотел остановиться на практической мелочи - подмене значений системного поля таблицы сущности Сделки в удобочитаемый вид.

Когда вы работаете с системными справочниками Битрикс24 CRM и дополняете их своими значениями, то в таблицу БД пишутся ровно системные значения, которые не связаны с вашим визуальным представлением. Давайте возьмем конкретное поле таблицы crm_deal и его поле crm_deal.TYPE_ID

crm_deal.TYPE_ID — это системное поле в таблице сделок (crm_deal) CRM Битрикс24, которое определяет тип сделки. Это поле используется для классификации сделок по различным бизнес-процессам или направлениям.

Основные особенности
Тип данных: строка (обычно кодовое обозначение типа сделки, например, SALE, GOODS, SERVICE и т.д.). Позволяет разделять сделки по направлениям, сценариям продаж или бизнес-процессам, а применяется для фильтрации, аналитики, автоматизации бизнес-процессов, построения отчетов.
Примеры значений:

  • SALE - Продажа.
  • GOODS - Продажа товаров.
  • SERVICE - Оказание услуг.
  • REPEAT - Повторная сделка.
  • CUSTOM - Пользовательский тип сделки.

Но после внедрения CRM конечно же появились свои типы и те, которые выходят за границы массива системных имеют просто порядковые целые значения: 1,2,3 и т.д. При формировании фильтров отчетов нехорошо выводит неинтерпретируемые значения полей - пользователи не обязаны "соображать" в этом огороде массива данных. Поэтому этот фактор нужно нивелировать и сделать это можно, используя конструкцию запроса в Trino.

Предварительно вы должны посмотреть все возможные значения, актуальные для вашей конфигурации справочника, либо через API, либо (метод попроще, но не очень правильный) через просмотр значений в таблице Сделки - crm_deal. Почему нехороший? Потому что пользователи, регистрируя сделки, могли не задействовать все типы сделок из вашего справочника. И есть еще 1 способ быстрого просмотра через отладчик браузера (F12), просматривая HTML код списка CRM. Этот же прием позволяет определить системные значения поля Тип сделки через настройки CRM в блоке справочника полей: CRM ➡️ Насторойки ➡️ Справочники ➡️ Тип сделки.

Я приведу в качестве примера только одно законченное выражение из блока SELECT:

 CASE crm_deal.TYPE_ID
     WHEN 'SALE' THEN 'Продажа'
     WHEN 'COMPLEX' THEN 'Проект'
     WHEN '1' THEN 'Рассрочка'
     ELSE 'Не определено'
 END AS "Тип сделки"

Краткое пояснение: 

  • Если TYPE_ID = 'SALE', результат — 'Продажа'
  • Если TYPE_ID = 'COMPLEX', результат — 'Проект'
  • Если TYPE_ID = '1', результат — 'Рассрочка'
  • Для всех остальных значений — 'Не определено'
  • А поле будет иметь название "Тип сделки"

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