Интеграцию 1С и Битрикс24 обычно настраивают один раз, радуются неделю, а потом начинается. В CRM у одного клиента три карточки. Менеджер видит в сделке старую сумму, потому что счёт в 1С поменяли, а обратно ничего не приехало. Отгрузка прошла, а сделка висит на этапе «ждём оплату». И никакой ошибки на экране: обмен как будто работает. Ниже разбираю ошибки обмена 1С и Битрикс24: откуда берутся дубли, почему обмен ломается молча и что проверить при настройке интеграции, чтобы этого не было.
Сразу про то, откуда я это знаю. Я не программист 1С и конфигурации не дорабатываю. Моя работа это стыки между системами: как они узнают друг друга, что происходит при сбое, кто узнает, что обмен встал. Для пары 1С и Битрикс24 эти вопросы те же, что для любой другой пары учётной системы и CRM. Детали про Битрикс24 в основном взяты из его документации, а поиск дублей по телефону я проверил на тестовом портале. Поведение 1С с телефонами я проверил на тестовой базе 1С:УНФ 3.0 в облачном 1С:Фреше. Где что проверено, пишу прямо.
Как устроен обмен между 1С и Битрикс24
У Битрикс24 есть коннектор к 1С для 1С:Бухгалтерии, 1С:Управления торговлей и 1С:УНФ. Что именно синхронизируется, зависит от конфигурации: с Бухгалтерией это счета, с Управлением торговлей сделки и заказы, с УНФ счета и сделки. Кроме коннектора есть модули сторонних разработчиков и самописные обмены через REST API Битрикс24 и OData или HTTP-сервисы 1С.
Способы разные, но задача у всех одна: две системы должны договориться, что карточка в CRM и контрагент в 1С это один и тот же клиент. Почти все проблемы растут отсюда.
Откуда берутся дубли
Системы по-разному понимают, что такое «клиент»
В Битрикс24 компания, её реквизиты, юридический и фактический адрес хранятся как разные сущности. В 1С это один контрагент. Обмен каждый раз переводит одно в другое, и любое расхождение в этом переводе оборачивается либо дублем, либо затёртыми данными.
Типичный сценарий: менеджер завёл компанию в CRM, а бухгалтер завёл того же контрагента в 1С по счёту раньше, чем сработал обмен. Теперь их двое, и обмен не знает, что это один клиент.
Телефон записан пятью способами
+7 999 111-22-33, 89991112233, 8 (999) 111 22 33. Для человека это один номер. Битрикс24 здесь умнее, чем я ожидал, и это я проверил на тестовом портале: его поиск дубликатов считает эти три записи одним номером, сам приводя к одному виду восьмёрку, скобки и пробелы.
Но код страны он за вас не допишет. Номер 999 111 22 33, записанный без +7, для него другой, и дублем тех трёх он не станет. То же с добавочным, записанным как «доб. 5»: с ним номер не совпал ни с одним из вариантов. Если телефоны приходят из сайта, из мессенджера, из 1С и от менеджеров руками, каждый источник пишет их по-своему, и часть дублей всё равно проскакивает.
В 1С:УНФ клиент от интеграции остаётся «без телефона»
С 1С история хитрее, и в ней я разобрался руками на тестовой базе УНФ. Когда телефон вводят в карточку контрагента вручную, 1С сохраняет отдельно нормализованный номер: для +7 999 111-22-33 это 79991112233, только цифры. Когда контрагента создаёт интеграция через OData (стандартный API 1С) и передаёт номер текстом, нормализованный номер остаётся пустым: при такой записи 1С номер не разбирает, даже если передать его по частям.
Я завёл одного клиента несколькими карточками, одни руками, другие через OData, и посмотрел, что видит 1С.
Контроль дублей. В УНФ он есть, но по умолчанию сверяет только ИНН и КПП. Я включил проверку по телефону. При вводе того же номера руками 1С нашла все «ручные» карточки и не показала ни одной созданной через OData, хотя у одной номер был записан символ в символ так же.
Подбор клиента в заказе. Если в поле «Покупатель» набрать номер, 1С подсказывает клиентов по нормализованному номеру и понимает и 9991112233, и 89991112233. Карточек, созданных через OData, в подсказках не было.
Поиск в списке контрагентов. Ищет по видимому тексту: номер с пробелами или дефисами по сплошным цифрам не находится вовсе, какой бы дорогой карточка ни пришла.
На практике это выглядит так: менеджер набирает номер клиента в заказе, 1С его не подсказывает, и менеджер заводит нового. Дубль появился, хотя обмен тут вроде бы ни при чём. Проверить свою базу можно за минуту: возьмите клиента, который точно пришёл через интеграцию, и наберите его номер в поле «Покупатель» нового заказа. Не подсказывает, значит, интеграция пишет телефоны так, что 1С их не видит.
Решение я тоже проверил: если интеграция сама заполняет нормализованный номер так же, как его заполняет ручной ввод, подбор в заказе находит такого клиента вместе с остальными. Контроль дублей сравнивает по тому же номеру, но отдельно для этого случая я его не проверял. Проверка была на УНФ 3.0 в 1С:Фреше и на мобильном номере РФ. Другие конфигурации 1С, запись через HTTP-сервисы и готовые модули обмена, а также городские и восьмисотые номера я не проверял.
Слишком много входов
Клиент оставил заявку на сайте, потом написал в мессенджер, потом ему выставили счёт в 1С. Если каждый канал создаёт карточку сам и не спрашивает, есть ли такой клиент, получится три карточки, и у каждой своя часть истории. Я разбирал это в посте про интеграцию CRM с мессенджерами и таблицами: дубли надо ловить в момент создания записи, а не раз в квартал.
Повтор после сбоя
Обмен отправил «создай контакт», Битрикс24 его создал, но ответ не дошёл: таймаут, сеть, перегрузка. Обмен решает, что запрос не прошёл, и отправляет его ещё раз. Второй контакт готов. Если у обмена нет правила «прежде чем создавать, проверь, не создал ли я это уже», каждый сбой связи оставляет после себя дубль.
Сбой связи не экзотика. На тестовой связке 1С → Битрикс24 из шестнадцати запросов один оборвался по таймауту, хотя такой же запуск минутой раньше прошёл чисто. Отсюда правило: повторять после сбоя можно поиск и обновление, а создание нельзя, пока не проверено, что запись ещё не создана.
Связь между системами потерялась
По документации Битрикс24 типовая интеграция хранит соответствие «этот объект 1С = эта карточка в CRM» на стороне 1С. Если при выгрузке 1С не находит в Битрикс24 карточку с сохранённым идентификатором (её удалили или слили с другой при чистке дублей), связь удаляется. При следующем обмене объект может приехать в CRM заново. Похожая история с адресом портала: связи хранятся в привязке к нему, и для смены адреса в 1С есть отдельная команда. Если адрес поменять в обход неё, обмен перестаёт узнавать старые записи.
Получается неприятная петля: дубли почистили руками, а обмен вернул часть из них обратно.
Почему обмен 1С и Битрикс24 ломается молча
Дубли хотя бы видно. Хуже, когда данные просто перестают ходить, а все думают, что «оно же само».
Лимиты Битрикс24. У REST API в облаке ограничена частота запросов (около двух в секунду при постоянной нагрузке) и суммарное время работы каждого метода в скользящем десятиминутном окне. Превысили порог, и метод блокируется, пока старые минуты не выйдут из окна. Массовая выгрузка номенклатуры или остатков из 1С в конце дня может упереться в эти лимиты: часть данных доезжает, часть нет.
Подписка. Для работы REST API и вебхуков в Битрикс24 нужна подписка на Маркет. Не продлили, и интеграции через REST отключаются. Узнают об этом обычно от менеджеров, а не от системы.
Изменения на стороне 1С. Обновили конфигурацию, поменяли права у пользователя, под которым работает обмен, переименовали реквизит. Обмен продолжает запускаться, но часть полей больше не находит или получает отказ.
Журнал, который никто не читает. Ошибки обмена обычно куда-то пишутся. Вопрос в том, смотрит ли туда кто-нибудь. Если журнал открывают, только когда клиент уже пожаловался, это не контроль, а архив.
Что делать
1. Решить, какая система главная для каждого типа данных
Контакты и сделки живут в CRM. Документы, оплаты и остатки в 1С. Вторая система получает копию и не правит её у себя. Пока это не решено, двусторонний обмен будет перетирать данные туда-обратно, и правильной версии не будет ни в одной из систем.
2. Выбрать ключ сопоставления и привести его к одному виду
Для компаний это ИНН (и КПП для филиалов). Для физлиц телефон или email. Телефон перед сохранением приводится к одному формату в каждом источнике, обязательно с кодом страны, а не только в обмене с 1С. Иначе поиск дублей в Битрикс24 так и будет пропускать часть совпадений.
Если интеграция пишет контрагентов в 1С, одного текста номера мало: она должна заполнять и нормализованный номер (те же цифры без пробелов и скобок, что 1С сохраняет при вводе руками), иначе 1С этих клиентов по номеру не увидит. В УНФ это проверено, для других конфигураций стоит проверить так же. А в самой 1С стоит включить контроль дублей по телефону: в УНФ по умолчанию он проверяет только ИНН и КПП.
3. Искать перед тем, как создавать
Любой вход, будь то сайт, мессенджер или 1С, сначала ищет клиента по ключу. Нашёл, значит обновляет. Не нашёл, создаёт. Нашёл двоих, значит не угадывает, а откладывает запись в очередь «разобрать руками» и сообщает человеку. Разобрать несколько спорных записей в неделю быстрее, чем раз в полгода разгребать завал дублей.
4. Сделать повтор безопасным
У каждого объекта в 1С есть уникальный идентификатор. Его стоит хранить в отдельном поле карточки в Битрикс24 и перед созданием проверять, нет ли уже записи с таким идентификатором. Тогда повтор после таймаута обновит существующую запись, а не создаст вторую. На тестовой связке я так и сделал: повторный запуск синхронизации шестнадцати контрагентов обновил все шестнадцать компаний в Битрикс24 и не создал ни одной.
5. Разобрать накопленное до того, как чинить поток
Если дубли уже есть, одного исправленного обмена мало. Сначала разовая сверка: прогнать базу через те же правила сопоставления, слить дубли, восстановить связи между системами. И только потом включать исправленный обмен, иначе он снова вернёт часть того, что вы слили. Защита по коду 1С здесь не поможет: она не даёт создать компанию дважды, но не знает, что девять разных контрагентов в 1С это один клиент. На стенде девять таких карточек из 1С приехали в Битрикс24 девятью компаниями.
6. Следить за стыком, а не за журналом
Нужен сигнал в рабочий чат, когда обмен не отработал, упёрся в лимит или несколько часов подряд ничего не передавал, хотя обычно передаёт. Как настроить такие сигналы без потока ложных тревог, я разбирал в посте про мониторинг.
Кто что делает
Если нужно поменять логику внутри 1С (доработать конфигурацию, дописать обработку), это работа программиста 1С, и у многих компаний он уже есть на обслуживании. Правила сопоставления, очередь спорных записей, безопасные повторы и сигналы о сбоях можно вынести в отдельный слой рядом с 1С, не трогая её конфигурацию. Тогда обновление 1С не ломает эту логику: она живёт снаружи. Этот слой и есть моя часть работы, о ней подробнее на странице интеграции с 1С.
С чего начать самому
Выгрузите из Битрикс24 контакты и компании, приведите телефоны к одному виду (хватит формулы в таблице) и посчитайте совпадения по телефону и ИНН. Доля дублей покажет, насколько всё запущено. Потом откройте журнал обмена за последний месяц и посмотрите, сколько там ошибок, о которых никто не знал. В 1С проведите тест из раздела про телефоны: номер клиента из интеграции в поле «Покупатель» нового заказа.
Если хотите посчитать, во что обходятся ручные сверки между 1С и CRM, в калькуляторе потерь есть сценарий «ручные стыки систем». А если нужен взгляд со стороны, напишите мне. Созвонимся на 30 минут и посмотрим, где у вас обмен теряет данные и что чинить первым.
Узнали свою ситуацию?
Обмен Битрикс24 с 1С и другими системами без дублей, сбои видны сразу. Как это устроено и сколько стоит, на странице «Интеграция Битрикс24».
Обсудить задачу