Интеграция 1С и CRM: как связать системы

Менеджер закрывает сделку в CRM — и идёт заводить того же клиента в 1С. Бухгалтерия проводит оплату — и пишет менеджеру, чтобы тот руками обновил статус. Пока системы не связаны, компания платит за каждую запись дважды: временем сотрудников и ошибками переноса. Мы в F³ делаем интеграции между 1С, CRM, сайтами и внутренними сервисами — и в этой статье разбираем, зачем связывать системы, какие бывают схемы обмена данными, что делать, если у системы нет API, и почему правильный первый шаг — пилот на одном обмене.

Зачем связывать 1С и CRM

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

• Двойной ввод. Каждый клиент, заказ и счёт заводится дважды: менеджером в CRM и бухгалтером в 1С. Это не только время — это два источника правды, которые неизбежно расходятся.
• Рассинхрон остатков и цен. Менеджеры и сайт продают по каталогу, который отстаёт от учётной системы: клиент заказывает товар, которого нет на складе, или по вчерашней цене.
• Счета и оплаты вручную. Менеджер не видит в CRM, оплачен ли счёт, — и дёргает бухгалтерию, а клиент ждёт подтверждения дольше, чем должен.
• Отчёты не сходятся. Продажи по CRM и продажи по 1С — разные цифры, и каждое совещание начинается с выяснения, какая из них настоящая.

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

Какие бывают схемы обмена

Универсального «коннектора для всего» не существует: схема обмена проектируется от процесса — какие данные, в какую сторону и с какой задержкой должны двигаться.

• Односторонний обмен. Данные идут в одну сторону: например, заказы из CRM выгружаются в 1С, обратно не возвращается ничего. Самая простая и предсказуемая схема — с неё чаще всего и стоит начинать.
• Двусторонний обмен. Системы обновляют друг друга: сделка в CRM создаёт заказ в 1С, оплата в 1С меняет статус сделки. Требует правил разрешения конфликтов: что происходит, если запись изменили с обеих сторон.
• Обмен по расписанию. Данные синхронизируются пакетами — раз в несколько минут или ночью. Подходит для справочников, остатков и цен, где задержка не критична.
• Обмен по событию. Изменение сразу уходит в соседнюю систему — через API и вебхуки. Нужен там, где важна скорость: оплата счёта, новый заказ с сайта.

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

Обмен 1С с сайтом

Частный случай той же задачи — обмен 1С с сайтом или интернет-магазином: каталог, цены и остатки выгружаются на сайт, заказы и оплаты возвращаются в учётную систему. Схема обычно комбинированная: справочники — пакетами по расписанию, заказы — по событию, чтобы клиент не ждал подтверждения.

Здесь же живёт классическая ловушка: выгрузка «всего каталога целиком», которая с ростом номенклатуры начинает занимать десятки минут и класть сайт в часы пик. Лечится инкрементальным обменом — передаются только изменения — и проектированием под реальные объёмы данных, а не под демо-каталог из ста позиций.

Что делать, если нет API

Типовая ситуация: со стороны CRM — современный API, а со стороны 1С — конфигурация десятилетней давности без внешних интерфейсов. Это не приговор, а развилка из нескольких вариантов.

• Доработка конфигурации. В 1С добавляется расширение или обработка, которая отдаёт и принимает данные. Самый чистый путь — если конфигурацию можно дорабатывать и есть кому её сопровождать.
• Обмен файлами. Системы обмениваются выгрузками по расписанию — старый, но живучий способ. Подходит для справочников и остатков, не подходит для событий реального времени.
• Промежуточный слой. Между системами ставится сервис-посредник: забирает данные доступным способом, приводит к общему формату и раздаёт остальным. Дороже на старте, но когда систем больше двух — единственный способ не утонуть в связях «каждая с каждой».

Какой вариант выбрать — вопрос брифа: смотрим на версию и состояние конфигурации, права на доработку и требования к скорости обмена. Отдельный случай — когда данные приходят вообще не из системы, а документами от контрагентов: PDF-счета, сметы, спецификации. Здесь работает ИИ-разбор документов — как в нашей системе разбора смет, которая превращает входящие PDF в готовые спецификации с кодами внутренней платформы заказчика.

Почему начинать с пилота на одном обмене

Оценку интеграционных проектов мы даём после брифа — до него любая цифра была бы гаданием: стоимость зависит от состояния систем, с которыми предстоит стыковаться, а оно выясняется на первых же вопросах. Стартуем всегда одинаково: пилот на одном обмене — самом болезненном. Например, «заказ из CRM создаёт документ в 1С»: от и до, с обработкой ошибок и мониторингом.

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

Если двойной ввод и расходящиеся отчёты — про вашу компанию, опишите свои системы на fcube.io: разберём их на брифе, предложим первый обмен для пилота и вернёмся с оценкой. Это бесплатно.

Частые вопросы