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

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

Ниже — практическая схема для дистрибьютора, у которого учёт живёт в 1С (чаще всего 1С:УТ, КА или ERP), а продажи, агенты и работа с клиентами — в CRM. Схема одинаково работает для готовой CRM и для системы, которую пишут под компанию.

Правило первое: у каждого справочника один хозяин

Хозяин — это система, в которой запись создаётся и правится. Вторая система получает копию и не имеет права её менять, а если очень нужно — отправляет запрос на изменение. Как только оба конца могут редактировать одно и то же поле, дубли и «перетирание» правок становятся вопросом времени.

Отдельно про контрагентов. В дистрибуции юрлицо и торговая точка — разные сущности: у одного ИП может быть пять магазинов, у сети — сотня адресов с одним ИНН. Если CRM хранит точку как «клиента» с ИНН, дубли гарантированы. Правильная модель: юрлицо (ИНН + КПП) → договоры → точки доставки. Подробнее о структуре данных — в статье что должна уметь CRM для дистрибьютора.

Правило второе: связывать по идентификаторам, а не по названиям

Каждая запись в 1С имеет уникальный идентификатор ссылки (GUID). Именно его CRM должна хранить у себя рядом со своим ID — и наоборот, если 1С принимает записи из CRM, в ней заводится реквизит «ID во внешней системе». Сопоставление по наименованию, артикулу или телефону годится только для первичной загрузки, и то под присмотром человека.

• Номенклатура: GUID из 1С плюс артикул для людей. Штрихкод — не ключ: у одного товара их бывает несколько, а у разных характеристик — одинаковые.
• Контрагенты: GUID из 1С, а при создании новой записи — проверка по паре ИНН + КПП до отправки. Реквизиты удобно подтягивать из ЕГРЮЛ через подсказки DaData, тогда агент не набирает название вручную и не ошибается в ИНН.
• Точки: собственный ID CRM, а в 1С — как адрес доставки или партнёр, в зависимости от конфигурации.
• Заказы: ID заказа в CRM передаётся в 1С и сохраняется в документе. Повторная отправка того же ID должна обновлять документ, а не создавать новый.

Как технически обмениваться: четыре варианта

У 1С нет одного «правильного» API, есть несколько механизмов. Выбор зависит от версии конфигурации, того, где стоит база (свой сервер, облако, 1С:Фреш), и от того, кто будет поддерживать доработки на стороне 1С.

На практике для дистрибьютора чаще всего работает связка: HTTP-сервис на стороне 1С для заказов и статусов плюс промежуточный слой (сервис интеграции) между CRM и 1С, который держит очередь, повторяет неудачные отправки и ведёт журнал. Прямой вызов «CRM → 1С» без очереди выглядит проще, но первый же регламентный простой 1С вечером пятницы превращается в потерянные заказы. Как такую интеграцию строим мы — на странице интеграция CRM с 1С.

Заказ: от заявки агента до отгрузки

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

1. Агент или клиент на портале создаёт заказ — статус «Черновик», живёт только в CRM.
2. Проверка: кредитный лимит, просрочка, минимальная сумма, наличие. Если данные о долге берутся из 1С, они должны быть свежими — иначе проверка формальная. Механику мы разбирали в статье кредитный лимит и отсрочка платежа в CRM.
3. Отправка в 1С — статус «Передан». 1С создаёт заказ покупателя, ставит резерв и возвращает свой номер.
4. Изменения после этого момента — только через 1С или через отдельный запрос на корректировку, который 1С принимает или отклоняет.
5. 1С возвращает статусы: «Собирается», «Отгружен» (с номером УПД и фактическим количеством), «Доставлен», «Оплачен».
6. CRM показывает агенту и клиенту фактическую отгрузку, а не исходную заявку — это важно для разбора недовложений.

Частичная отгрузка — норма для дистрибуции, а не исключение. Если обмен передаёт только «отгружен / не отгружен», агент не узнает, что из 40 позиций уехало 36, и точка позвонит с претензией ему, а не складу. Передавайте построчное фактическое количество.

Остатки и цены: как часто синхронизировать

«В реальном времени» — дорогое и не всегда нужное требование. Задайте вопрос иначе: сколько стоит ошибка из-за устаревшего остатка? Для ходового товара с ежедневной отгрузкой сотен коробок задержка в час уже приводит к обещаниям того, чего нет. Для медленной номенклатуры хватает обновления раз в 15–30 минут.

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

Как убрать дубли, которые уже есть

Если интеграция работает давно, чистка — отдельный небольшой проект. Порядок такой.

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

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

Журнал обмена и мониторинг

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

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

Объём работ по интеграции сильно зависит от конфигурации 1С и числа потоков. Прикинуть его можно в калькуляторе стоимости внедрения CRM с 1С. Если вы ещё выбираете саму систему, посмотрите, что входит в CRM для оптовой торговли, и сравнение вариантов в статье своя CRM или amoCRM/Битрикс24. А если выясняется, что 1С:УТ сама по себе уже не тянет процессы, читайте когда 1С:УТ мало и что достраивать.