14.09.2026 · блог

Выгрузка данных из CRM в отчёты по расписанию: как настроить

Автоматическая выгрузка из CRM нужна, если отчёт каждую неделю собирают руками: фильтр, экспорт в Excel, сводная таблица, отправка руководителю. Ниже разберём, какими способами это настраивается, как сделать выгрузку, которая не сломается через месяц, и где чаще всего бывают ошибки.

Три способа настроить выгрузку по расписанию

Способ зависит от того, насколько отчёт стандартный и сколько систем в нём участвует.

• Встроенные отчёты CRM. В amoCRM и Битрикс24 есть своя аналитика по сделкам и воронкам. Если нужных цифр в ней хватает, дальше можно не идти. Но данные из других систем (1С, сайт, рекламные кабинеты) туда не попадают, а нестандартные разрезы собрать сложно.
• Сервисы-коннекторы. Готовые конструкторы связывают CRM с таблицей без программирования. Они хорошо справляются с простыми сценариями вроде «новая сделка — новая строка». Хуже у них с пересчётом истории, объединением нескольких источников и нестандартной логикой. Кроме того, данные проходят через сторонний сервис, а это важно, если в CRM есть персональные данные.
• Свой скрипт через API на сервере. Скрипт по расписанию забирает данные через API CRM, приводит их к нужному виду и записывает в таблицу или базу. На старте работы больше, зато логика может быть любой, а данные остаются на вашем сервере.

Бывает, что API у системы нет или он закрыт тарифом. Тогда остаётся выгрузка через веб-интерфейс: скрипт открывает настоящий браузер, входит под учётной записью и скачивает тот же файл, который сотрудник скачивал руками. Так медленнее, и при изменении интерфейса скрипт придётся править, но способ рабочий.

Как устроена выгрузка, которая не ломается

Техническая часть обычно проще, чем кажется. Ошибки чаще возникают из-за несогласованных правил: что считать сделкой, по какой дате её учитывать, в каком часовом поясе.

• Описать отчёт письменно. Какие поля, какие фильтры и какая дата: создания, закрытия или последнего изменения. Если этого не сделать, автоматизация просто повторит путаницу.
• Забирать только изменения. При каждом запуске скрипт берёт записи, изменённые с прошлого раза, и обновляет их в таблице по идентификатору. Так выгрузка не упирается в лимиты API и не плодит дубли.
• Подтягивать справочники. Вместо названий API отдаёт идентификаторы этапов, ответственных и пользовательских полей. Справочники нужно выгружать отдельно и регулярно обновлять.
• Хранить снимки. CRM показывает только текущее состояние: если сделка перешла на другой этап, прежний в карточке уже не виден. Чтобы видеть динамику воронки по неделям, скрипт должен сохранять срез на каждую дату.
• Запускать по таймеру. На Linux для этого есть cron или таймеры systemd. Время запуска выбирайте так, чтобы выгрузка закончилась раньше, чем кто-то откроет отчёт.
• Сообщать о сбоях. Если выгрузка упала, человек должен узнать об этом сразу, например из сообщения в Телеграм. Иначе проблему заметят через неделю по пустому отчёту.

Снимки мы используем и сами: при сборе цен с маркетплейсов храним каждый замер, а не только последний. База истории выросла примерно до 3,8 ГБ, и только по ней видна динамика, которой нет в самом источнике. С данными CRM принцип тот же.

Где выгрузки обычно ломаются

• Истёк токен доступа. При авторизации по OAuth токен нужно периодически обновлять. Если обновление не заложено, выгрузка в какой-то момент просто перестанет работать.
• Постраничная выдача. API отдаёт данные порциями. Если скрипт не проходит все страницы, он выгрузит только часть сделок. Цифры будут выглядеть правдоподобно, но окажутся неверными.
• Лимиты запросов. При превышении лимита CRM временно отклоняет запросы, поэтому в скрипте нужны паузы и повторы.
• Переименовали или удалили поле. Кто-то поменял настройки воронки, и столбец в отчёте опустел. Такое сразу ловит проверка структуры при каждом запуске.
• Часовой пояс. Сервер, CRM и таблица могут работать в разных поясах, и тогда сделки на границе суток попадают не в тот день.
• Удалённые записи. Выгрузка изменений видит правки, но удалённую сделку из таблицы сама не уберёт. Нужна отдельная сверка.
• Тихий сбой. Самый дорогой случай: скрипт завершился без ошибки, но данных нет. Проверяйте не только сам факт запуска, но и число выгруженных строк.

Куда выгружать и где это должно работать

Для отчёта руководителю обычно хватает таблицы: её легко просматривать и строить по ней сводные. Если данных много или CRM нужно объединить с 1С и сайтом, удобнее складывать всё в базу, а в таблицу отдавать уже готовые срезы.

Отдельный вопрос — на чём запускать скрипт. Компьютер сотрудника не подойдёт: его выключат на ночь или сотрудник уйдёт в отпуск, и отчёта не будет. Нужен сервер, который работает круглосуточно. Если в CRM есть персональные данные клиентов, по 152-ФЗ их нужно хранить в базах на территории России. Это стоит учесть при выборе сервера и промежуточных сервисов.

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