Отчёт маркетинга в Битрикс24: заявки, дилерские передачи и оплаченные сделки

Отчёт может показать больше продаж после одного изменения учёта: дилер начал присылать статусы, ранее неизвестные сделки получили отметку «успешно», а их суммы попали в график. Коммерческая работа могла не измениться. Улучшилась видимость данных. Чтобы отличить эти ситуации, отчёт связывает отдельные события — поступление обращения, передачу, принятие, сделку и оплату — и показывает, где сведения ещё неизвестны.

Ниже — техническая модель для поставщика семян и СЗР с дилерской сетью. Она проверена на вымышленном наборе событий; к реальной CRM материал не подключался. Документация Битрикс24 сверена на 10 октября 2026 года. Модель можно адаптировать и к другим категориям АПК, если определить собственные сущности, источник денег и правила связи.

Начать с единицы строки

Проблема многих отчётов возникает раньше графика. Один лид имеет две передачи дилерам, одна сделка — три товарные строки и два платежа. Если соединить всё напрямую, каждый платёж повторится в строках каждого товара и каждой передачи. Даже правильные исходные данные дадут завышенную сумму.

В предлагаемой схеме есть пять самостоятельных объектов. Потребность — задача покупателя по продукту и сроку. Отправка — событие формы, звонка или сообщения. Передача — конкретная попытка адресовать потребность дилеру. Сделка — конкретная согласованная закупка. Платёж — отдельное денежное событие. У каждого объекта свой номер, а переходы сохраняются как события.

Потребность ──► несколько обращений
     ├───────► несколько попыток передачи ──► дилеры
     └───────► одна или несколько сделок
                              └───────────► платежи

Отдельные закупки одного хозяйства не объединяются только по ИНН. Несколько предложений по одной закупке не считаются несколькими продажами. Эти решения принимаются в CRM и сохраняются в связях; BI должен воспроизводить их, а не угадывать по одинаковому названию клиента.

Что дают штатные наборы Битрикс24

Официальная документация описывает наборы лидов, сделок, пользовательских полей, истории стадий, дел и смарт-процессов. Есть и внешние источники, в том числе CSV. Доступность BI и объём данных зависят от тарифа. Перечень наборов BI.

Связь лид → сделка через LEAD_ID описана в документации лидов и сделок. Если портал работает без лидов или сделка пришла из внешней системы, этот путь не появляется автоматически. Для таких записей нужен собственный устойчивый номер потребности и таблица соответствий. Наборы лидов, наборы сделок.

Для смарт-процесса набор называется crm_dynamic_items_ с идентификатором типа. Его связи с CRM доступны в crm_entity_relation. Этот набор не хранит стандартную связь лида и сделки, поэтому использовать его как универсальную таблицу всех отношений нельзя. Наборы смарт-процессов.

Успех сделки и поступление денег

В crm_deal есть сумма и семантика стадии. Они полезны для коммерческого отчёта, но не превращаются в банковский факт. Особенно опасно использовать CLOSEDATE как дату оплаты: в документации набора это планируемая дата закрытия сделки. Денежный отчёт должен получить отдельную дату платёжного события. Описание полей сделки.

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

Если оплаты действительно созданы в интернет-магазине используемого портала, официальный REST-метод sale.payment.list возвращает их список. В ответе предусмотрены orderId, paid, datePaid, sum, currency; метод требует scope sale и администратора. Размер страницы — 50 записей, поэтому выгрузка одной страницы не гарантирует полноту. orderId надо связать с бизнес-сделкой: совпадение числовых ID разных сущностей не является связью. Справочник sale.payment.list.

Этот метод не раскрывает платежи независимого дилера в его учётной системе. Для них нужен согласованный экспорт или интеграция. Достаточный набор включает номер связанной сделки/заказа, ID платежа, сумму, валюту, дату, статус и источник подтверждения. Отгрузку, возврат и платёж лучше хранить отдельными типами событий. УПД сам по себе не задаёт дату получения денег.

Две даты для запоздавших сведений

У события сохраняют время совершения и время получения. Платёж поступил 5 октября, а дилер отправил его в отчёт 8 октября. В денежном отчёте событие относится к 5 октября. В версии отчёта на 6 октября оно ещё неизвестно. Без двух дат нельзя объяснить, почему сумма прошлого периода выросла после новой выгрузки.

Когорта по дате регистрации отвечает на вопрос, что произошло с обращениями определённого месяца. Отчёт по дате оплаты отвечает на вопрос, какие подтверждённые деньги поступили за месяц. Эти группировки нужны одновременно. Поздняя оплата сентябрьского обращения в октябре остаётся связанной с сентябрьской когортой, но не становится сентябрьским денежным поступлением.

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

Соединять после отдельной агрегации

Удобный порядок расчёта состоит из трёх операций. Сначала исключить повторные доставки одного события по event_id, сохранив журнал входящих строк. Затем посчитать платежи по payment_id и сделке, передачи — по transfer_id и потребности. После этого соединить уже агрегированные результаты с одной строкой каждой потребности. Если один event_id пришёл с разными суммами или другим бизнес-содержимым, это конфликт: обе версии изолируют для разбора, а не выбирают первую. В примере повтор отличается только временем получения; платёжные сведения совпадают.

Проверка перед соединением: действительно ли в выбранной таблице одна строка на объявленный ключ. Если нет, сначала уточняют ключ либо агрегируют записи. COUNT(DISTINCT request_id) исправляет число потребностей, но не исправляет сумму повторённых платежей. У каждого показателя должна быть своя единица расчёта.

В приложении SQL выполняется над учебной нормализованной таблицей events, а не напрямую над порталом Битрикс24. Логика имеет такой вид:

WITH payments AS (
  SELECT deal_id, SUM(CAST(amount AS NUMERIC)) AS confirmed_cash_rub
  FROM events
  WHERE event_type = 'payment_confirmed'
  GROUP BY deal_id
)
SELECT w.deal_id, p.confirmed_cash_rub
FROM won_deals w
LEFT JOIN payments p ON p.deal_id = w.deal_id;

won_deals здесь обозначает предварительно подготовленный список успешных сделок; полный исполняемый запрос в приложении создаёт его отдельным выражением. Отсутствующая платёжная строка остаётся NULL. Состояние «неизвестно» передаётся отдельным признаком; сумма наблюдаемых платежей не называется полной суммой продаж сети.

Исполненный пример: 30 строк событий

Все номера начинаются FAKE_, компании и платежи вымышлены. Набор включает повтор формы, повтор доставки платёжного события, отказ дилера, тайм-аут, переназначение, ответ в следующем месяце, отмену и неизвестную оплату. Расчёт выполнен скриптом со стандартной библиотекой Python, а табличный результат дополнительно получен SQL-запросом в SQLite.

По оплате сведения есть для одной из двух успешных сделок: охват составляет 50%. Это не утверждение, что другая сделка неоплачена. Сумма 100 000 рублей описывает подтверждённую часть; полный денежный результат неизвестен. Повтор платёжного события исключён, а две попытки передачи одной потребности не умножили платёж.

На конец сентября содержательный ответ имели три потребности. К 10 октября их четыре: один ответ произошёл 1 октября. Отчёт хранит оба среза логически раздельно, поэтому улучшение обработки видно без переноса самой заявки в октябрь.

Исправление платежа должно оставаться отдельным событием

Возврат, отмену и исправление суммы связывают с исходным платёжным ID. Если повторная выгрузка присылает то же событие, она не добавляет ещё одно поступление. Если данные изменились, сохраняют версию и основание изменения. Для частичного возврата отдельно показывают поступление, возврат и итог по выбранному правилу; одна текущая сумма без истории скрывает движение денег.

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

Как перенести модель в BI

Для первого испытания можно импортировать учебную таблицу или агрегированный результат CSV. Документация описывает загрузку файла, настройку колонок и типов. Даты следует передать однозначно, сумму — числом, неизвестное значение — пустым с отдельным состоянием. Обновление файла и периодичность получения данных необходимо организовать отдельно. Создание CSV-датасета.

Затем составляют карту соответствий: бизнес-поле → CRM-сущность → техническое поле → источник → правило преобразования. Реальные UF-поля и ID смарт-процессов получают в конкретном портале. REST-справочник предусматривает crm.item.fields для актуального перечня полей; универсальные и старые методы используют разные формы имён. Метод crm.item.fields требует scope crm и права чтения элементов соответствующего типа. Нельзя переносить условный номер UF из примера документации в собственную выгрузку. Получение полей, поля объектов CRM.

Доступ к просмотру отчёта и доступ к созданию датасета проверяются отдельно. В BI предусмотрены роли и права на группы отчётов; настройка зависит от тарифа. Для дилерских данных нужно испытать, что каждый участник действительно видит допустимые сведения, а фильтр графика не используется как единственный механизм ограничения. Права доступа BI.

Для облака проверяют доступность нужных функций и лимитов в действующем тарифе. Для коробки фиксируют редакцию и установленный релиз, затем наличие наборов на стенде. Конкретный набор, ограничения и права подтверждают на стенде выбранной установки. Учебный Python/SQLite-расчёт не проверяет REST-подключение, схемы SQL Битрикс24 или обновление производственного BI-отчёта.

Приёмка завершается сверкой: количество потребностей объясняется отправками и повторами; количество передач — номерами попыток; денежная сумма — отдельными платёжными ID; неизвестные оплаты видны. У отчёта указаны период, дата среза и охват. Тогда вопрос «откуда это число» имеет проверяемый ответ в данных, а изменение отчётности не маскируется под изменение продаж. Отчёт по заявкам и оплаченным сделкам не заменяет цену одного принятого обращения. Как считать стоимость B2B-заявки, которую взял отдел продаж, отделяет сырой лид от того, что уже в воронке.