Обмен 1С и Битрикс24 настраивал для розничных и оптовых компаний примерно десяток раз - от разовой выгрузки контрагентов до двусторонней синхронизации сделок, счетов и оплат в реальном времени. Стандартный модуль обмена закрывает базовый сценарий: перенос номенклатуры, контрагентов, заказов. Но как только в цепочке появляется эквайринг, СДЭК или сайт на Tilda с отдельной формой заявки, приходится дорабатывать обмен руками - через REST API Битрикс24, HTTP-сервисы 1С или связку на n8n.
Как устроена интеграция 1С и Битрикс24: два рабочих сценария
Первый вариант - штатный модуль обмена, который в 1С-Битрикс: Управление сайтом называется CommerceML, а в коробочном Битрикс24 подключается как «1С:Обмен данными». Он работает по расписанию: 1С формирует XML-файлы с контрагентами, номенклатурой и заказами, Битрикс24 их забирает через HTTP-соединение и разбирает. Схема надёжная для каталога и заказов интернет-магазина, но плохо подходит для CRM-сущностей вроде сделок и счетов - там нет гибкой настройки статусов и полей.
Второй вариант - обмен через REST API Битрикс24 и вебхуки. Скрипт-прослойка на Python или PHP подписывается на события ONCRMDEALADD, ONCRMDEALUPDATE, ONCRMINVOICEADD и при срабатывании обращается к HTTP-сервису 1С (или OData) для записи или чтения данных. Это дольше в разработке, зато позволяет синхронизировать именно то, что нужно бизнесу: статусы сделок, суммы, привязку к контрагенту, номер и статус счёта.
| Критерий | Штатный обмен (CommerceML) | REST API + вебхуки |
|---|---|---|
| Что синхронизирует | Номенклатура, контрагенты, заказы | Сделки, счета, статусы оплат, кастомные поля |
| Периодичность | По расписанию (обычно раз в 5-30 минут) | Почти в реальном времени, событийно |
| Настройка | Через интерфейс, без кода | Требует разработки скрипта-прослойки |
| Риск задвоений | Средний при ручных правках на стороне 1С | Низкий при правильной идемпотентности |
На практике чаще нужна комбинация: каталог и заказы идут через штатный обмен, а сделки, счета и статусы оплат - через отдельный REST-скрипт, потому что бизнес-логика воронки в CRM не укладывается в формат CommerceML.
Синхронизация контрагентов: как избежать задвоений компаний и контактов
Самая частая головная боль - задвоение контрагентов. В Битрикс24 сущности «Компания» и «Контакт» разделены, а в 1С обычно один справочник «Контрагенты» с реквизитами. Если сопоставлять записи только по названию компании, через месяц в базе будет три «ООО Ромашка» с разными ИНН или без них вообще.
Рабочий подход: сопоставление строго по ИНН (для юрлиц и ИП) или по телефону в формате +7XXXXXXXXXX (для физлиц). В Битрикс24 под это заводится пользовательское поле UF_CRM_1C_ID у компании и контакта - туда пишется код контрагента из 1С при первой синхронизации. Дальше поиск дубликатов идёт по этому полю, а не по имени.
Второй момент - нормализация адресов и телефонов перед записью. 1С и Битрикс24 хранят телефон в разных форматах (с скобками, дефисами, без кода страны), и если не приводить к единому виду на этапе обмена, дедупликация по номеру просто не сработает. Обычно нормализацию делаю прямо в скрипте-прослойке перед записью в любую из систем - это надёжнее, чем полагаться на встроенные фильтры Битрикс24.
Обмен сделками между 1С и Битрикс24: статусы, суммы, воронка
Сделки - самая чувствительная часть обмена, потому что от корректных статусов зависит финансовая отчётность и мотивация менеджеров. Настраиваю так: у каждой сделки в Битрикс24 есть поле с ID документа из 1С (заказа или счёта), и обмен идёт по нему, а не по названию сделки или сумме.
Стадии воронки маппятся вручную - таблица соответствия «стадия в Б24» → «статус документа в 1С» обычно из 6-10 пар значений. Например, стадия «Успешно» в Битрикс24 соответствует проведённому заказу в 1С, а «Отменена» - статусу «Аннулирован». При изменении стадии сделки срабатывает вебхук, скрипт находит связанный документ в 1С по ID и меняет его статус через HTTP-сервис.
Основная опасность - циклическая перезапись. Если синхронизация двусторонняя (1С может менять статус в Битрикс24, а Битрикс24 - статус в 1С), без защиты от зацикливания система начинает бесконечно переписывать одно и то же поле туда-обратно. Решается через метку источника изменения: при записи в любую систему добавляется технический флаг «изменено обменом», и на этапе обработки события скрипт проверяет - если флаг стоит, повторную запись не делает.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Счета и оплаты: как передать документ и статус оплаты в 1С
Счёт, выставленный менеджером в Битрикс24, должен появиться в 1С как основание для отгрузки, а факт оплаты - вернуться обратно в CRM, чтобы менеджер видел актуальный статус без захода в бухгалтерию. Логика такая: при создании счёта в Битрикс24 (событие ONCRMINVOICEADD) скрипт создаёт в 1С счёт на оплату или заказ покупателя с привязкой к контрагенту по ИНН.
Статус оплаты обычно приходит не из 1С напрямую, а от эквайринга - если приём платежей настроен через Т‑Банк или другой банк с вебхуками, событие об оплате логичнее ловить сразу на стороне сайта или платёжного шлюза и параллельно писать в 1С и в Битрикс24, а не гонять статус между CRM и учётной системой. Похожая схема у меня отработана на интернет-магазинах на WooCommerce с оплатой через Т‑Банк: вебхук о поступлении денег обновляет заказ в CMS и одновременно триггерит запись в 1С.
Если в процессе участвует доставка, статус трек-номера СДЭК тоже логично синхронизировать в оба направления: 1С или склад проставляет номер отправления, он попадает в сделку Битрикс24 и в письмо клиенту, а статус «Вручено» от СДЭК меняет стадию сделки на «Выполнена». Пример готовой логики такой интеграции с трансформацией статусов можно посмотреть в библиотеке готовых скриптов - там есть заготовки под похожие связки CRM и служб доставки.
Пример обработчика вебхука сделки на Python
@app.route('/webhook/deal-update', methods=['POST'])
def deal_update():
data = request.json
deal_id = data['data']['FIELDS']['ID']
deal = bitrix.call('crm.deal.get', {'id': deal_id})
if deal.get('UF_SYNC_SOURCE') == '1C':
return '', 200 # изменение пришло из 1С, не пишем обратно
doc_id = deal.get('UF_CRM_1C_ID')
stage_map = {'WON': 'Проведён', 'LOSE': 'Аннулирован'}
new_status = stage_map.get(deal['STAGE_ID'])
if doc_id and new_status:
odata_1c.update_document(doc_id, status=new_status)
return '', 200
Ошибки при настройке обмена 1С и Битрикс24, которые встречаю чаще всего
- Нет уникального поля-связки между сущностями - сопоставление идёт по имени или сумме, и при малейшем расхождении система создаёт дубль вместо обновления.
- Двусторонняя синхронизация без защиты от циклической перезаписи - поля меняются туда-обратно, в логах десятки лишних записей в минуту.
- Отсутствие логирования и повторных попыток - если 1С временно недоступна (обновление конфигурации, блокировка базы), событие из Битрикс24 просто теряется без ретрая.
- Проблемы с кодировкой - 1С исторически работает с Windows-1251, Битрикс24 и REST API - с UTF‑8; без явного преобразования кириллица в названиях контрагентов превращается в набор кракозябр.
- Слишком частый опрос вместо событийной модели - при поллинге раз в минуту вместо вебхуков на несколько сотен сделок нагрузка на 1С-сервер растёт неоправданно.
Отдельно стоит сказать про часовые пояса: если 1С стоит на сервере с одним TZ, а Битрикс24-облако работает в UTC, даты создания и изменения документов могут расходиться на несколько часов - это ломает логику «синхронизировать только изменённое после последнего запуска».
Сроки и стоимость настройки обмена данных 1С-Битрикс24
Простая доработка - донастройка полей в существующем обмене, добавление сопоставления статусов, фикс задвоений - занимает 3-5 рабочих дней и стоит от 20 000 ₽, это уровень точечного скрипта на Python поверх вебхуков.
Полноценная двусторонняя интеграция сделок, счетов и оплат с нуля, с обработкой ошибок, логированием и повторными попытками - от 3 до 5 недель, стоимость от 150 000 ₽, потому что по объёму работы это ближе к отдельному веб-сервису, чем к разовому скрипту. На рынке за интеграцию такого уровня студии обычно просят 150 000-400 000 ₽ в зависимости от количества сущностей и сложности маппинга статусов - у меня цена стартует с той же нижней границы, но без наценки за бренд студии.
Если обмен уже работает и нужно только его сопровождать - мониторить падения вебхуков, чинить расхождения после обновлений 1С, докручивать маппинг при изменении воронки, - это уже не разовая доработка, а регулярная задача.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Можно ли настроить обмен 1С и Битрикс24 без программиста, только штатным модулем?
Для каталога, заказов интернет-магазина и базового переноса контрагентов - да, штатный модуль CommerceML настраивается через интерфейс и не требует кода. Но как только нужна синхронизация статусов сделок, кастомных полей или счетов с привязкой к оплате, штатных настроек не хватает и нужна доработка через REST API.
Как часто должна происходить синхронизация - в реальном времени или по расписанию?
Для каталога и остатков достаточно расписания раз в 15-30 минут - это снижает нагрузку на 1С-сервер. Для сделок, счетов и статусов оплаты лучше событийная модель через вебхуки: менеджер и клиент должны видеть актуальный статус сразу, а не через полчаса.
Что делать, если после настройки обмена задваиваются контрагенты?
Обычно причина в сопоставлении по названию компании вместо ИНН или телефона. Нужно завести техническое поле с ID из 1С у компании и контакта в Битрикс24, прогнать разовый скрипт дедупликации по существующей базе, а дальше сопоставлять только по этому полю.
Нужен ли обмен 1С-Битрикс24, если у нас всего 50 сделок в месяц?
При таком объёме часто достаточно ручного переноса счетов или простого экспорта раз в день без полноценной интеграции - экономия времени менеджера будет небольшой, а стоимость разработки не окупится быстро. Автоматизацию обмена имеет смысл делать, когда объём сделок растёт до сотен в месяц или когда ошибки ручного переноса уже стоят компании денег и времени бухгалтерии.