Обмен между CRM и 1С ломается не из-за технологий, а из-за неправильно выбранной схемы и двойного ввода. Разбираем три рабочие схемы обмена данными, их сильные и слабые стороны и как выбрать подходящую под ваш тип учёта.
Ошибки в остатках появляются не тогда, когда «криво настроили обмен», а тогда, когда одни и те же данные правятся в двух системах сразу. Рабочая интеграция начинается с простого правила: у каждого вида данных есть ровно один хозяин — одна система, где их заводят и меняют.
Если в 1С сейчас бардак — обмен это не исправит, а разнесёт бардак по двум системам. Об этом честно говорим в четвёртом разделе.
Схемы отличаются тем, какая система главнее и что куда передаётся. Правильная схема определяется не возможностями коннектора, а тем, как устроен ваш учёт.
Каталог, цены и остатки живут в 1С и только там редактируются. Битрикс24 подтягивает их для менеджеров и отправляет в 1С готовые заказы. Подходит, когда учёт в 1С уже налажен, товаров много и остатки меняются каждый день.
Слабая сторона. В CRM есть только то, что есть в 1С: новый товар появится у менеджеров после того, как его заведёт учёт. Если товарный справочник в 1С запущен, CRM это унаследует.
Самая частая схема. Сделки и заказы менеджеры ведут в Битрикс24, готовый заказ уходит в 1С на резерв и отгрузку, а статусы оплаты и доставки возвращаются в карточку сделки. Каждая система отвечает за свой отрезок.
Слабая сторона. Конфликты при правках с двух сторон: менеджер поменял состав заказа в CRM, кладовщик — в 1С. Без правила «кто и на каком этапе что редактирует» схема начинает плодить расхождения.
Битрикс24 — продажи и клиенты, 1С — бухгалтерия и склад, а обмениваются системы только контрагентами и счетами. Подходит для услуг и простого учёта, где остатки менеджерам не нужны вовсе.
Слабая сторона. Остатков и статусов отгрузки в CRM нет — на вопрос клиента «когда мой заказ?» менеджер по-прежнему звонит на склад. Для торговли товаром со склада схема обычно слабовата.
Когда остатки в CRM и 1С расходятся, первым делом ругают обмен. На практике обмен обычно работает как настроен — проблема в том, что происходит вокруг него.
Менеджер правит заказ в CRM, кладовщик — тот же заказ в 1С, и ничьё изменение не дожидается обмена. Через месяц системы расходятся, и никто не помнит, где правда. Лечится правилом «один вид данных — один хозяин», а не более частым обменом.
Если в 1С товар заведён трижды под разными именами, а инвентаризация была год назад, интеграция честно перенесёт этот бардак в CRM. Сначала порядок в учёте, потом обмен — в обратном порядке получите два бардака вместо одного.
Интеграция не чинит учёт. Она честно переносит данные из одной системы в другую — вместе с порядком или вместе с бардаком.
Выбор схемы — это ответы на вопросы про ваш учёт, а не про возможности коннектора. Запуск — строго по этапам, иначе первый же сбой похоронит доверие к обмену.
Где живёт каталог товаров и кто его заводит? Где резервируются остатки — в момент заказа или отгрузки? Как часто меняются цены и кто их меняет? Из ответов складывается схема: товарный учёт налажен — первая, заказы рождаются в CRM — вторая, остатки менеджерам не нужны — третья.
Каталог и цены правятся только в 1С. Заказ до передачи в учёт — только в CRM, после — только в 1С. Контрагенты — в одной системе, выбранной заранее. Правило короткое, но именно оно избавляет от ошибок в остатках: править одни и те же данные в двух местах больше нельзя.
Сначала обмен поднимается на копии базы и тестовом портале: гоняются реальные заказы прошлого месяца, сверяются остатки и суммы. Только когда копия сходится с оригиналом, обмен переводят на боевые системы.
Сначала синхронизируются контрагенты и номенклатура, неделю-две обмен работает только на них. Потом подключается передача заказов. Остатки и статусы — последними, когда первые два этапа стабильны. Каждый этап заканчивается сверкой, а не просто «заработало».
Менеджер видит остаток и цену в карточке сделки и отвечает клиенту сразу, без звонка на склад.
Счёт, выставленный из CRM, совпадает с тем, что видит бухгалтерия в 1С, — до копейки и до позиции.
Заказ существует в одном экземпляре: никто не перезаводит его руками «на всякий случай», потому что обмен отработал молча.
Расхождения видны отдельным списком: если что-то не ушло или не пришло, это замечают в тот же день, а не на инвентаризации.
Статус оплаты и отгрузки возвращается в карточку сделки сам — клиенту отвечают из CRM, а не из бухгалтерии.
При сбое обмена понятно, что делать и кто отвечает: сбой — событие, а не повод вернуться к ручному переносу.
Если после запуска обмена кто-то продолжает переписывать данные руками «для надёжности» — обмен не запущен, а добавлен третьим местом учёта. Это самый дорогой вариант из всех.
Зависит от схемы. Для минимального контура и простой передачи заказов стандартного обмена обычно хватает. Доработки нужны, когда логика сложнее: резервирование на нескольких складах, спецификации производства, разные типы цен для разных клиентов. Правильный порядок — сначала выбрать схему, потом смотреть, закрывает ли её стандартный модуль. Покупать доработку «про запас» не стоит.
С основными учётными: Управление торговлей, Комплексная автоматизация, ERP, УНФ. Чем старше и сильнее переписана конфигурация, тем больше вероятность доработок обмена. Отдельный случай — самописные и сильно доработанные конфигурации: там объём работ определяется только после осмотра базы, и честный ответ «сколько это стоит» возможен только после него.
Разным данным — по-разному. Заказам и статусам оплаты нужна скорость: здесь обмен по событию или каждые несколько минут. Каталогу и ценам обычно достаточно расписания — ночью или несколько раз в день. Требование «всё в реальном времени» удорожает обмен и нагружает обе системы, а пользы для большинства компаний не даёт.
С учёта, а не с интеграции. Пока в 1С один товар заведён трижды, а остатки не сходятся со складом, обмен только разнесёт это в CRM. Сначала наводится порядок в номенклатуре и остатках — это работа вашего учётчика или 1С-специалиста, — и только потом настраивается обмен. Мы всегда предупреждаем об этом до начала работ: интеграция с запущенным учётом — деньги на ветер.
Минимальный контур — от нескольких дней. Двусторонний обмен заказами с тестом на копии и поэтапным запуском — обычно несколько недель, и большая часть срока уходит не на техническую настройку, а на согласование правил: кто хозяин данных, на каком этапе заказ передаётся, что делать при правках. Точный срок зависит от состояния учёта и конфигурации — поэтому называется после разбора, а не до него.
На короткой встрече разберём, как устроен ваш учёт, скажем, какая из трёх схем вам подходит и хватит ли стандартного обмена. Если проблема в самом учёте, а не в интеграции, — скажем и это. Встреча на 40 минут, без обязательств продолжать.
