Подключили «Битрикс24» к 1С — и получили дубли, старые остатки и ручную сверку. Где ошиблись

Привет, VC.

Меня зовут Алексей Постригайло, я старший партнер ИТ-интегратора «Энсайн». Больше 20 лет занимаюсь разработкой и внедрением корпоративных систем.

Есть одна история, которая в разных вариациях повторяется довольно часто.

Компания подключает «Битрикс24» к 1С. На тестах все выглядит нормально: клиент передался, заказ создался, статус вернулся. Интеграцию принимают, сотрудники начинают работать.

Через пару недель оказывается, что часть контрагентов задублировалась. Остатки в CRM иногда отличаются от 1С. Бухгалтерия просит менеджеров дополнительно присылать номера заказов в чат. А оплаченные сделки все равно приходится проверять вручную.

То есть обмен есть, но доверия к нему нет.

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

Обычно начинают искать ошибку в модуле. На практике причина часто находится совсем в другом месте.

Никто заранее не договорился, что именно должно происходить между двумя системами.

У «Битрикс24» и 1С разные роли.

В CRM менеджер ведет клиента: фиксирует обращение, переписку, звонки, договоренности, двигает сделку по этапам.

В 1С находится учетная часть: контрагенты, номенклатура, цены, заказы, счета, оплаты, остатки, отгрузки.

До интеграции информация обычно ходит между отделами через людей. Менеджер пишет бухгалтеру. Бухгалтер заводит заказ. После оплаты сообщает об этом обратно. Склад отдельно подтверждает наличие.

Задача интеграции, как я ее понимаю, не в том, чтобы связать две базы. Она должна убрать эти ручные переходы.

Менеджер оформил сделку в «Битрикс24». В 1С появился заказ. Поступила оплата — статус вернулся в CRM. Товар отгрузили — менеджер увидел это в карточке клиента.

Если после внедрения сотрудники продолжают звонить друг другу и сверять данные, значит мы автоматизировали не тот процесс. Или вообще его не описали.

Штатный коннектор здесь не виноват. Он выполняет то, что ему настроили.

Но он не знает, кто в компании отвечает за реквизиты. Не знает, разрешено ли менять заказ после передачи в 1С. Не понимает, что делать, если менеджер и бухгалтер одновременно исправили одну карточку.

Это должны решить люди до запуска.

На старте проекта часто звучит вполне понятное пожелание:

— Сделайте так, чтобы клиента можно было менять и в 1С, и в «Битрикс24».

Технически сделать можно.

Допустим, менеджер обновил телефон клиента в CRM. Почти одновременно бухгалтер исправил данные того же контрагента в 1С.

При следующем обмене одна версия перезапишет другую. Какая именно — зависит от настроек, времени изменений и очередности синхронизации.

Для пользователей это выглядит примерно так: вчера телефон был правильный, сегодня снова старый. Кто его вернул и почему, никто не понимает.

Начинается обычная история:

— Это 1С затерла данные.— Нет, это менеджер в CRM что-то поменял.— А какая система вообще главная?

Последний вопрос нужно было задать первым.

Мы обычно предлагаем разделить ответственность примерно так: сделки и коммуникации остаются в «Битрикс24», номенклатура, цены, остатки и учетные документы — в 1С. Оплата и отгрузка фиксируются в 1С и возвращаются в CRM в виде статусов.

У конкретной компании схема может быть другой. Тут нет единственно правильного варианта.

Но вариант должен быть выбран.

Двусторонний обмен не означает, что все можно менять везде. Иначе это не интеграция, а постоянный спор двух источников данных.

Возьмем простой сценарий.

Менеджер нажимает кнопку в CRM. Запрос уходит в 1С. Заказ успешно создается, но в этот момент обрывается соединение.

«Битрикс24» не получает подтверждение и считает, что операция не прошла. Через некоторое время отправляет запрос еще раз.

Дальше возможны два варианта.

В первом 1С создает второй заказ. Бухгалтерия позже замечает дубль и начинает выяснять, какой документ настоящий.

Во втором интеграция проверяет уникальный идентификатор запроса, находит уже созданный заказ и просто возвращает его номер.

Для менеджера оба сценария выглядят одинаково. Он нажал одну кнопку.

Но именно такие детали определяют, будет система работать годами или сотрудники каждую неделю станут разбирать последствия.

Интеграция должна быть готова к повторным запросам. Связь между объектами двух систем нужно хранить явно. Сделка в CRM должна знать, с каким заказом в 1С она связана. И наоборот.

Это особенно важно для счетов, оплат и отгрузок. Здесь дубли уже влияют не только на удобство, но и на учет.

Еще одна частая ошибка — желание запустить весь контур одним большим проектом.

Клиенты, контакты, товары, цены, остатки, сделки, заказы, оплаты, резервы, отгрузки. И еще несколько пользовательских полей, которые «наверняка пригодятся».

На схеме все выглядит логично. В реальной работе ошибки начинают накладываться друг на друга.

Заказ не передался из-за клиента или из-за товара? Остаток неправильный из-за обмена или из-за логики резервирования? Документ задублировался или пользователь создал его вручную?

Разбираться в таком клубке тяжело.

Я бы начинал с одного короткого маршрута.

Например: менеджер создает сделку в «Битрикс24», после согласования в 1С формируется заказ, а после оплаты CRM получает новый статус.

Все.

Сначала нужно добиться, чтобы этот процесс работал стабильно. Без звонков, повторного ввода и ручной сверки.

Потом можно добавлять резервирование, отгрузку, товары и остатки.

Это не попытка искусственно растянуть проект. Наоборот, так намного быстрее становится понятно, где реальная проблема.

Есть не самая приятная часть интеграции, которую иногда пытаются пропустить.

К моменту запуска обе системы уже заполнены.

В «Битрикс24» накопились компании и контакты. В 1С есть контрагенты. У одной организации может быть несколько карточек. Названия записаны по-разному. Где-то нет ИНН. Телефоны хранятся в разных форматах.

Если просто включить обмен, старый беспорядок начнет размножаться.

ООО «Ромашка», «Ромашка» и «Ромашка, ООО» человек легко распознает как одну компанию. Система может решить, что это три разных контрагента.

Поэтому до первого массового обмена данные приходится сопоставлять.

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

По названию сопоставлять опасно.

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

Еще одна фраза, которую часто слышишь на старте:

— У нас стандартная 1С, там ничего сложного.

Потом выясняется, что конфигурация обновлялась несколько лет назад, внутри десятки собственных обработок, а заказы вообще ведутся в документе, которого нет в типовой поставке.

1С — это не одна программа.

Это может быть «Бухгалтерия предприятия», «Управление торговлей», УНФ, ERP или сильно измененная конфигурация. У компании может быть несколько баз, между которыми уже работает собственный обмен.

Поэтому до оценки нужно хотя бы зафиксировать точную конфигурацию, редакцию, версию платформы и список значимых доработок.

Иногда штатный коннектор действительно закрывает почти всю задачу. Тогда нет смысла писать интеграцию с нуля.

Иногда типовым модулем можно передать только часть данных, а главная бизнес-логика находится в собственных документах. Тогда потребуется доработка.

Оба варианта нормальные. Плохо только выяснить это после обещанного срока запуска.

Я бы всегда начинал с проверки штатного решения.

Если конфигурация типовая, а компании нужно передавать стандартных клиентов, товары, заказы и оплаты, возможностей коннектора часто достаточно.

Это быстрее. Обычно дешевле. Проще поддерживать после обновлений.

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

Иногда между «Битрикс24» и 1С появляется отдельный сервис. Он принимает сообщения, хранит очередь, повторяет запросы после сбоев и фиксирует результат.

Но отдельный интеграционный слой — не обязательный признак серьезного проекта. Если задача решается штатно, не надо строить лишнюю систему ради самой архитектуры.

На практике часто получается смешанный вариант. Типовые данные идут через коннектор. Специфические операции — через отдельную обработку или сервис.

Обычно тестируют позитивный сценарий.

Создали сделку. Передали в 1С. Увидели заказ. Все довольны.

Но это проверка соединения, а не надежности.

Я бы обязательно посмотрел, что случится, если запрос уйдет повторно. Если 1С станет недоступна. Если у клиента не заполнен обязательный реквизит. Если товар отправлен в архив. Если документ успел создаться, но ответ не вернулся.

Пока такие ситуации не проверены, интеграцию рано отдавать всем пользователям.

Первый контур лучше ограничить: одна база, одно юридическое лицо, один вид заказа, несколько менеджеров.

И уже на нем пройти не только нормальный путь, но и несколько аварийных.

Интеграция начинает показывать свое настоящее качество именно в момент, когда что-то пошло не по плану.

Сбой когда-нибудь случится.

Истечет пароль служебной учетной записи. Остановится сервис. После обновления изменится поле. Один документ перестанет проходить из-за новых данных.

Вопрос не в том, можно ли навсегда исключить ошибки. Нельзя.

Вопрос в другом: когда компания об этом узнает?

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

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

Я бы постоянно контролировал четыре вещи: время последнего успешного обмена, количество сообщений в очереди, число ошибок и возраст самой старой проблемы.

Не обязательно строить огромную панель мониторинга. Но эти данные должны быть видны.

Журнал, который открывают только после жалобы пользователя, — это архив, а не контроль.

Интеграции нередко настраивают от имени разработчика, администратора или руководителя отдела.

Работает — и хорошо.

Через год человек увольняется. Его учетную запись блокируют. Вместе с ней перестают работать вебхуки или часть запросов.

После этого начинается поиск того, кто вообще настраивал обмен и где лежат доступы.

Для интеграции нужна отдельная служебная учетная запись с ограниченными правами.

Компания должна понимать, для чего она используется, где хранятся данные доступа и какие процессы остановятся при ее блокировке.

Критичный обмен между системами не должен зависеть от личного аккаунта сотрудника.

Когда к заказам добавляются товары, цены, остатки и резервы, интеграция становится заметно сложнее.

Нужно сопоставить номенклатуру, склады, единицы измерения, ставки НДС, типы цен. Договориться, где находится главный каталог.

Если товары ведутся в 1С, нет смысла разрешать менеджерам вручную менять их цены в CRM.

С остатками тоже не все очевидно.

Какую цифру показывать менеджеру? Физический остаток? Доступное количество? Остаток за вычетом резервов? По одному складу или по всем?

Если заранее это не определить, в карточке сделки появится точное число, которому нельзя доверять.

Поэтому складской контур я бы подключал после того, как стабильно заработали клиенты и заказы. Иначе в одном запуске смешаются проблемы с контрагентами, номенклатурой, ценами и резервами.

После запуска интеграцию часто оставляют разработчикам.

Это ошибка.

Техническая команда отвечает за соединение, очереди, доступы и ошибки. Но она не должна решать, можно ли менять заказ после передачи в 1С или какой статус считать финальным.

Для этого нужен владелец со стороны бизнеса.

Человек, который понимает, как работают продажи, бухгалтерия и склад, и может принять решение при конфликте.

Иначе каждая проблема превращается в переписку между отделами.

Технически обмен может работать исправно. Но если никто не отвечает за правила, процесс все равно будет разваливаться.

Не после установки модуля.

Не после демонстрации.

И даже не после первого месяца без критических ошибок.

Интеграция закончена, когда сотрудники перестали делать лишнюю работу.

Менеджер не заводит заказ второй раз. Бухгалтер не пишет об оплате в чат. Повторный запрос не создает дубль. Ошибка видна сразу, а зависшую операцию можно безопасно запустить повторно.

После обновления 1С или CRM проводится проверка, а не ожидание первого инцидента.

Если данные продолжают выгружать в Excel и периодически сверять вручную, проект пока не завершен.

Штатно подключить «Битрикс24» к 1С обычно можно без большого проекта.

Но само подключение мало что меняет.

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

Коннектор передает информацию. Он не отвечает за ее смысл и качество.

Мы в «Энсайн» начинаем такие проекты с разбора текущего процесса. Смотрим, где сотрудники повторно вводят данные, как между отделами передаются заказы и оплаты, в каких местах информация уже расходится.

После этого становится понятно, хватит ли штатного коннектора или потребуется отдельная логика.

И цель здесь довольно простая: сотрудники должны работать с клиентами и документами, а не обслуживать интеграцию между двумя системами.