Коннектор включён. Почему данные всё равно расходятся?
Коннектор умеет перевозить данные. Он не решает, какая система права. Если менеджер меняет телефон клиента в Битрикс24, а бухгалтер исправляет тот же телефон в 1С, без заранее заданного правила победит не лучший вариант, а последний записанный.
До первой настройки ответьте на пять вопросов: что передаём, кто имеет право это менять, по какому постоянному идентификатору записи (внешнему ID) системы узнают один объект, что запускает обмен и кто разбирает конфликт. Иначе технически успешный обмен легко создаст второй заказ, вернёт старую цену или оставит оплаченную сделку в статусе «Не оплачено».
Проверка за 15 минут: откройте один реальный заказ и выпишите четыре строки: клиент, товар, заказ, оплата. Если у строки нет владельца, внешнего ID и понятного действия при сбое, выбирать коннектор пока рано.
Какой способ связи вам действительно нужен
Связать Битрикс24 и 1С можно по-разному. Начинайте с самого простого варианта, который закрывает конкретную задачу.
- Штатная синхронизация передаёт компании, контакты, реквизиты, товары, сделки, счета, заказы, оплаты, отгрузки и смарт-процессы в пределах поддерживаемой конфигурации.
- Коннектор позволяет работать с 1С из Битрикс24: создавать документы и справочники, получать печатные формы, запускать роботов и триггеры.
- Точечное приложение закрывает один поток, например возвращает оплату, показывает остаток или помогает подобрать товар.
- Собственный интеграционный слой нужен для нетиповых объектов, особых правил, нескольких баз или требований к восстановлению, которых нет в готовом решении.
| Задача | С чего начать | Где чаще ошибаются |
|---|---|---|
| Вернуть факт оплаты в сделку | Точечное приложение или один поток | Не учли частичную оплату, отмену и ID документа |
| Передавать товары, цены и остатки | Штатная синхронизация | Перепутали версию обмена, прайс или склад |
| Создавать заказы из сделок и возвращать статусы | Штатный модуль или профильное приложение | Не сопоставили статусы, оплату, доставку и повтор |
| Связать нетиповые объекты и правила | Собственный слой через API и события | Не заложили очередь, лимиты и поддержку |
Сначала проверяйте штатный путь на своей конфигурации. Заказная разработка нужна не потому, что она звучит солиднее, а когда вы можете назвать конкретный пробел: объект не поддерживается, баз несколько, правило нетиповое или готовое решение не показывает и не восстанавливает сбои.
Один заказ вместо туманного ТЗ: собираем договор о данных
Перед настройкой мы собираем одну таблицу. В ней видно, кто создаёт клиента, откуда приходит цена, как возвращается оплата и что делать, если системы не согласны. Эту таблицу одинаково понимают продажи, бухгалтерия, специалист 1С и разработчик.
Для каждого объекта достаточно зафиксировать шесть вещей:
- поля, которые действительно нужны в обмене;
- систему-владельца и сотрудников, которые могут менять данные;
- внешние ID Битрикс24 и 1С после первой подтверждённой привязки;
- направление и момент обмена;
- как приводим данные к нужному формату и чьё значение побеждает при расхождении;
- повтор, журнал, уведомление и способ контрольной сверки.
Не пишите в ТЗ «двусторонний обмен клиентами». Клиент слишком большой объект. Телефон и ответственный могут жить в CRM, а ИНН, КПП и банковские реквизиты подтверждаться в 1С. Если разрешить обеим системам перезаписывать всё, одна из них обязательно вернёт старое значение.
Где обмен ломается чаще всего
Клиент уже не тот: как не привязать заказ к чужой карточке
У двух филиалов может быть общий телефон. Один адрес почты может принадлежать целому отделу. У одного юрлица встречаются разные КПП. Поэтому автоматическое слияние по одному признаку иногда прикрепляет новый заказ к чужой карточке.
Базовая синхронизация проверяет телефон и электронную почту. В расширенных правилах можно сопоставлять название, телефон, почту и ИНН/КПП в нужной комбинации. Если найдено несколько кандидатов, обмен должен остановиться и позвать человека, а не угадывать.
| Этап | Правило | Бизнес-смысл |
|---|---|---|
| Первая привязка | Телефон / электронная почта / ИНН/КПП по согласованной комбинации | Найти вероятную пару, не объявляя её истиной |
| Неоднозначность | Остановить и отправить ответственному | Не связать заказ с чужим контрагентом |
| После подтверждения | Сохранить внешние ID обеих систем | Не искать пару заново по изменяемым реквизитам |
| Изменение реквизитов | Принять значение только от владельца поля | Не вернуть старые данные следующим обменом |
Товары, цены и остатки: один артикул, несколько вариантов
Для торгового контура 1С часто отвечает за SKU, характеристики, единицы измерения, цены и остатки. В складском режиме 1С товары и документы в Битрикс24 нельзя редактировать. Правило прозрачное: менеджер видит данные, но не создаёт вторую версию учёта.
В товарном обмене есть важная развилка. Формат v1 не поддерживает вариации и несколько прайсов, а v2 работает с вариациями, остатками и прайсами. В v2 цена и доступное количество привязаны к торговым предложениям. Отключите их выгрузку, и карточка появится без нужной цены или остатка.
Перед пилотом проверьте пять вещей:
- какой ID переживёт переименование товара и изменение артикула;
- как связаны базовый товар и характеристика;
- какую цену и валюту видит менеджер;
- какой склад и резерв формируют доступный остаток;
- что происходит с товаром, архивированным только в одной системе.
Заказ оплачен, а сделка об этом не знает
Этап сделки отвечает на вопрос «что делает команда продаж?». Статус заказа, оплаты или отгрузки показывает, что произошло в учёте. Это разные процессы. Если свести их в один список, менеджер начнёт закрывать сделку бухгалтерским действием, а бухгалтерия случайно сдвинет воронку продаж.
В настройке заказов отдельно сопоставляются статусы, платёжные системы и службы доставки. Пропустите этот шаг, и может определиться неверная платёжная система, а служба и стоимость доставки не передадутся. Для счетов и сделок правила также зависят от конфигурации: «Бухгалтерия предприятия», УНФ, УТ и ERP не равны друг другу.
Зелёная галочка ещё ничего не доказывает. Представьте: 1С создала заказ и вернула файл счёта, но статус оплаты не обновился. Документ на месте, а менеджер всё равно пишет оплатившему клиенту. Проверяйте не вызов API, а то, увидел ли человек правильный результат.
Храните у заказа внешние ID обеих систем, а не только номер: он может зависеть от организации, префикса и правил нумерации. У оплаты и отгрузки сохраняйте ID операции, сумму, дату и связь с заказом. Частичная оплата нормальна. Ненормально, если повтор одного события увеличил сумму второй раз.
Что мы знаем о 1С:Фреш из практики
Мы в 13FOX уже настраивали обратную запись через 1С:Фреш в действующем клиентском проекте. Этот опыт быстро отучает верить одной фразе «Фреш поддерживается». Важно не название продукта, а конкретный путь: кто вызывает сервис, какие объекты он читает и записывает, какие права получает и как команда увидит ошибку.
Битрикс24 поддерживает работу с 1С:Фреш, но не любым способом. В сервисном режиме Push&Pull может быть недоступен. Для HTTP-варианта нужно опубликовать сервис и выдать права на нужные операции.
До оценки мы проверяем:
- точную конфигурацию и редакцию;
- можно ли подключить нужное расширение;
- какие HTTP-сервисы и внешние интерфейсы доступны;
- может ли каждая сторона инициировать нужный вызов;
- как протестировать чтение, запись и повтор без риска для рабочего учёта.
Главный вывод из нашего проекта простой: обратную запись нельзя оставлять «на потом». Для неё с самого начала нужны свои ID, правило повтора, разбор конфликта и контрольная сверка.
«В реальном времени» ещё не означает «надёжно»
Битрикс24 поддерживает ручной запуск, расписание и обмен по событию. Полную синхронизацию используют для первого заполнения, затем передают изменения. Выбирать один режим для всех данных не нужно.
| Режим | Когда подходит | Главный риск |
|---|---|---|
| Ручной | Редкая операция, нужен контроль бухгалтера | Забыли запустить или выбрали не тот документ |
| По расписанию | Допустима задержка, важна простая эксплуатация | Ошибка обнаружится позже; нужна сверка пакетов |
| По событию | Статус сразу меняет действие пользователя | Всплеск, повтор, потеря обработчика, частичный успех |
Товары можно обновлять по расписанию, а оплату возвращать сразу после события. Но если 1С не ответила, команда должна увидеть сбой, а операция должна дождаться безопасного повтора. Поэтому режим выбирают не только по скорости, но и по поведению при ошибке.
Что должно произойти, если ответ потерялся
Сначала быстро сохраните входящее событие в очередь, верните ответ Битрикс24 и обработайте запись в 1С фоном. Так долгий учётный процесс не держит платформу в ожидании.
Если 1С временно недоступна, повторите операцию несколько раз с растущей паузой. После лимита попыток передайте ошибку ответственному. Бесконечный цикл только прячет проблему.
Самый опасный момент возникает, когда заказ в 1С уже создан, но ответ не вернулся. Следующий запрос должен найти этот заказ, а не создать новый. Такой безопасный повтор называется идемпотентностью.
Журнал обязан отвечать на обычные вопросы: что передавали, какие ID связали, где произошла ошибка, сколько было попыток и кто её разбирает. Отладочные записи не храните бесконечно: они раздувают базу 1С.
Главный тест повтора: отправьте заказ в 1С и оборвите ответ после создания. Запустите событие ещё раз. Если появился второй заказ, интеграция тест не прошла.
Иногда большая интеграция вообще не нужна
Представьте, что менеджеру нужен только факт оплаты. Один поток из 1С в сделку решит задачу быстрее и потребует меньше поддержки, чем двусторонняя синхронизация клиентов, товаров, заказов и документов.
Выбирайте простое решение, когда:
- операция редкая и безопасно подтверждается вручную;
- допустима периодическая CSV-выгрузка;
- нужен только остаток, оплата или печатная форма;
- одна из систем используется как просмотр, а не рабочий контур;
- поддержка сложного обмена стоит дороже понятного ручного процесса.
Как мы запускаем пилот, чтобы ошибка не ушла во все сделки
Мы не начинаем с полного архива и всех воронок. Берём одну организацию, один склад, одну воронку или один тип заказа. Сначала проверяем обычный путь и неприятные исключения. Только потом добавляем следующий поток.
В тестовую выборку специально добавляем неудобные случаи:
- нового и существующего клиента;
- неоднозначный дубль;
- товар с характеристикой;
- заказ со скидкой и доставкой;
- частичную оплату;
- отмену или возврат;
- временную ошибку и повтор;
- объект, который ожидаемо не синхронизируется.
Затем проверяем простые контрольные правила: сумма строк, доставки и скидки совпадает с итогом; оплата не превышает сумму документа; валюта и НДС не изменились; один внешний ID не связан сразу с двумя объектами. Критическая ошибка останавливает расширение пилота.
Восемь вопросов подрядчику до сметы
- Какие конфигурации, редакции и версии поддерживает выбранный способ?
- Какие поля идут в каждую сторону и какая система владеет каждым из них?
- Как проходит первая привязка и где сохраняются ID Битрикс24 и 1С?
- Что происходит, если найдено несколько клиентов или контрагентов?
- Как связаны этапы сделки, статусы заказа, оплата и доставка?
- Что произойдёт, если объект создан, но ответ потерялся?
- Где видны очередь, попытки, причина ошибки и ответственный?
- Что входит в приёмку и что останется у заказчика: схема, таблица, код, доступы и регламент?
Короткие ответы на частые вопросы
Что можно синхронизировать между Битрикс24 и 1С?
Компании, контакты, реквизиты, товары, сделки, счета, заказы, оплаты, отгрузки и другие объекты. Точный набор зависит от конфигурации 1С, версии модуля и выбранного способа связи.
Какая система должна быть главной: Битрикс24 или 1С?
Одна главная система для всего не нужна. Битрикс24 обычно ведёт работу менеджера и путь клиента, а 1С хранит учётные данные, товары, оплаты и документы. Владельца назначают для каждого объекта или поля.
Можно ли интегрировать Битрикс24 с 1С:Фреш?
Да, но сначала нужно проверить конфигурацию, права и доступный способ связи. В сервисном режиме Push&Pull может быть недоступен; для HTTP нужны опубликованный сервис и права на нужные операции.
Как избежать дублей клиентов и контрагентов?
Задайте правила первой привязки по телефону, почте, ИНН/КПП или их комбинации. Неоднозначные пары отправляйте человеку. После подтверждения сохраните внешние ID обеих систем и больше не ищите запись заново по изменяемым реквизитам.
Нужен ли обмен в реальном времени?
Только там, где задержка меняет действие человека или системы. Оплату можно возвращать по событию, а товары обновлять по расписанию. Режим выбирают отдельно для каждого объекта.
Как понять, что интеграция готова к запуску?
Данные контрольных заказов совпали в обеих системах, ошибки видны, повтор не создаёт второй заказ или платёж, у каждого сбоя есть ответственный, а команда умеет сверить результат после обмена.
На что мы опирались
Технические детали сверены по официальным материалам 30 июля 2026 года. Перед запуском проверьте их для своей конфигурации 1С и версии модуля.
- Битрикс24: интеграции с 1С, обновлено 6 мая 2026 года.
- Битрикс24: возможности интеграции и заявленная поддержка 1С:Фреш, доступ 30 июля 2026 года.
- Битрикс24: режимы и общие настройки синхронизации, обновлено 29 июня 2026 года.
- Битрикс24: настройка интеграции объектов, обновлено 29 июня 2026 года.
- Битрикс24: синхронизация товаров, обновлено 29 июня 2026 года.
- Битрикс24: складской учёт в режиме 1С, обновлено 23 июля 2026 года.
- Битрикс24: синхронизация сделок, обновлено 29 июня 2026 года.
- Битрикс24: синхронизация счетов, обновлено 29 июня 2026 года.
- Битрикс24: синхронизация заказов, обновлено 29 июня 2026 года.
- Битрикс24: правила сопоставления объектов, обновлено 29 июня 2026 года.
- Битрикс24: настройка коннектора, транспорта и оповещений, обновлено 23 июля 2026 года.
- Битрикс24 REST API: лимиты и повтор с задержкой.
- Битрикс24 REST API: входящая очередь событий.
- Битрикс24 REST API: офлайн-события.
- 1С: программные интерфейсы подсистемы Фреш, изменено 24 июня 2026 года.
Читайте также: как выбрать CRM-архитектуру, если системы ещё не выбраны, и как связать магазин, CRM и 1С при маркировке товаров.
Разберём один заказ до оценки всего проекта
Пришлите пример заказа, список систем с точными версиями и ответственных со стороны продаж и учёта. На первой встрече мы определим владельцев полей, направления, ID, точки отказа и контрольные сценарии.
После встречи у вас останется карта обмена с рисками. По ней станет понятно, хватает ли штатной синхронизации, нужен ли точечный модуль или задачу лучше решить проще.