Интеграция CRM с 1С: зачем и как связать продажи с учётом

Зачем связывать CRM с 1С: одна продажа, две системы

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

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

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

Какие данные ходят между CRM и 1С и кто источник правды

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

Самая недооценённая строка — клиенты. До запуска обмена нужно зафиксировать правило сопоставления: по какому ключу системы понимают, что это один и тот же клиент. Для юрлиц это обычно ИНН плюс КПП, для физлиц — телефон или почта. И отдельно решить, что делать с уже накопленными дублями: мержить их после запуска обмена в разы дороже, чем до.

CRM-системы с интеграцией с 1С: что умеют штатные коннекторы

У популярных готовых CRM «интеграция с 1С» заявлена в списке возможностей, и для типового случая это правда. Вопрос в том, что считать типовым случаем — и что происходит за его границей:

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

API-интеграция с маркетплейсами и платежами: тот же контур продаж

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

• Маркетплейсы по API: заказы забираются в учёт или CRM, остатки и цены уходят на площадки. У каждой площадки свой API со своими лимитами и версиями — интеграция должна переживать и лимиты, и изменения формата.
• Эквайринг и платежи: вебхук об оплате закрывает счёт в 1С и двигает сделку в CRM — вместо ручной отметки «оплачено со слов клиента».
• Телефония: звонок поднимает карточку клиента в CRM и остаётся в истории; пропущенный звонок становится задачей, а не потерянным лидом.
• Внутренние системы: если у компании своя внутренняя система или B2B-кабинет, они встают в тот же контур — заказ из кабинета доезжает до учёта тем же слоем, что и сделка из CRM.

Именно поэтому интеграцию стоит проектировать как один слой с общим журналом, а не как три независимых коннектора: когда обмены живут порознь, каждый падает по-своему, и никто не видит картину целиком. Если же задача не в обмене, а в операционке маркетплейсов целиком — сборка, поставки, сверки выплат, — это отдельное направление SellerOps back-office.

Что делает обмен CRM и 1С надёжным

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

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

Сколько стоит интеграция CRM с 1С

Цена зависит от количества систем в контуре, состояния их API, объёма данных и требований к надёжности. Ориентиры — те же, что на странице интеграций и API:

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

Что решить до старта: шесть вопросов

Ответы на эти вопросы определяют и архитектуру, и бюджет — и сэкономят вам первую неделю проекта:

1. 1Какая CRM и какая конфигурация 1С, дорабатывались ли они и кем. «Типовая, но чуть поправленная» — это доработанная.
2. 2Сколько юрлиц и баз 1С участвует в продажах и должна ли CRM видеть их как одно целое.
3. 3По какому ключу сопоставляются клиенты (ИНН/КПП, телефон, почта) и кто разберёт накопленные дубли до запуска.
4. 4Где рождается счёт и кто владеет его номером — CRM или 1С. Двойная нумерация всплывает в первый же отчётный период.
5. 5Какие события нужны быстро (оплата — сразу в CRM), а какие достаточно гонять по расписанию (номенклатура — раз в сутки). Требование «всё онлайн» удорожает обмен без пользы.
6. 6Кто со стороны компании отвечает за 1С и кто принимает решения об источниках правды — это бизнес-решения, разработчик их за вас не примет.