Интеграция 1С и Битрикс 24: как не автоматизировать хаос

Самир Алиев, руководитель отдела разработки и интеграции 1С компании «Авиант», - о том, как подготовить компанию к интеграции 1С и CRM.

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

Иногда интеграция 1С и Битрикс24 не устраняет хаос. Она его автоматизирует.

Пока они занимаются этой бесконечной рутиной, бизнес платит за одну и ту же работу как минимум четыре раза.

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

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

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

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

После оплаты информация появляется в 1С. Но в Битрикс24 сделка может продолжать находиться на стадии «Счет отправлен».

Ответьте себе на вопрос: можете ли вы за 5 минут чётко ответить,

• где находится актуальная информация о клиенте;
• какая система — 1С или Битрикс24 — является источником цены;
• где хранится основная версия заказа;
• в какой системе фиксируется оплата?

А теперь задайте эти же вопросы продажам, бухгалтерии и IT.

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

Что необходимо определить до начала работ:

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

Без этих правил интеграция не создаёт единый цифровой контур. Она переносит существующие противоречия между сотрудниками в автоматизированный обмен между системами.

На демо-встречах клиенты очень часто начинают разговор с вопроса о коннекторах и выборе между кастомной и стандартной интеграцией — а иногда и с более общего вопроса, нужен ли Битрикс24, если уже есть 1С.

Мы в ответ начинаем задавать вопросы, без которых не видим смысла что-либо интегрировать, — и клиент не может дать на них ответ. Вот эти вопросы:

• что считать главным — заказ в CRM или документ в 1С;
• кто может менять цену — только менеджер или ещё и бухгалтер;
• что именно означает статус «оплачено»;
• где должна храниться актуальная карточка клиента.

Приведу пример конкретной ситуации:

Менеджер меняет цену товара в Битрикс24. В это же время бухгалтер формирует документы в 1С по старой цене.

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

Но какая цена должна считаться правильной?

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

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

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

Интегратору приходится превращать внутренние противоречия компании в код:

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

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

При интеграции интегратор не придумывает логику обмена данными. Его задача — зафиксировать API-контракт (например, на основе REST API Битрикс24 и штатного плана обмена платформы 1С) и превратить договорённости (или хаос) между системами в код обработки запросов. По сути, интегратор создаёт единую точку входа для данных — но правила, по которым эта точка принимает решения, должны быть согласованы бизнесом заранее, а не выведены программистом эмпирически в процессе разработки.

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

Сначала необходимо определить бизнес-логику и договориться об этом внутри своей компании:

• кто отвечает за данные;
• где они создаются;
• кто может их изменять;
• когда информация считается подтверждённой;
• что делать при возникновении противоречий.

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

Перед интеграцией 1С и Битрикс24 необходимо описать правила работы с каждым ключевым объектом: клиентом, ценой, заказом и оплатой.

Объект	Источник данных	Кто отвечает	Кто может менять	Приоритет при расхождении
Клиент	Битрикс24 (карточка)	Отдел продаж	Менеджер, реже — бухгалтер	Определяет ответственный сотрудник
Цена	1С (расчёт)	Коммерческий отдел / бухгалтерия	Менеджер (со скидкой), бухгалтер (в документе)	1С перезаписывает цену в CRM
Заказ	CRM → 1С после проведения	Отдел продаж, затем бухгалтерия	До проведения — менеджер, после — ограничено	Версия в 1С считается финальной
Оплата	1С	Бухгалтерия	Только бухгалтерия	1С — единственный источник статуса оплаты

Какая система является источником данных

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

Например:

• карточка клиента создаётся и актуализируется в Битрикс24;
• номенклатура и остатки передаются из 1С;
• цена рассчитывается в 1С;
• заказ создаётся в CRM, но после проведения в 1С становится учётным документом;
• факт оплаты фиксируется в 1С и передаётся в Битрикс24.

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

Кто отвечает за актуальность информации

У каждого вида данных должен быть владелец. Важно определить:

• кто отвечает за карточку клиента;
• кто контролирует цены и скидки;
• кто отвечает за состав и статус заказа;
• кто подтверждает поступление оплаты;
• кто разбирает спорные ситуации.

Без владельца ошибка остаётся общей проблемой, за исправление которой фактически никто не отвечает.

Кто имеет право изменять данные

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

• может ли бухгалтер изменить цену, согласованную менеджером;/li>
• может ли менеджер редактировать заказ после создания документов в 1С;/li>
• кто может объединять дубли клиентов;/li>
• можно ли изменить реквизиты после оплаты;/li>
• кто имеет право отменить заказ или вернуть его на предыдущий этап./li>

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

Какая система имеет приоритет при расхождениях

Нужно заранее определить, что произойдёт, если одна и та же информация изменится одновременно в 1С и Битрикс24. Например:

• цена из 1С всегда перезаписывает цену в CRM;
• после проведения заказа в 1С редактирование состава в Битрикс24 блокируется;
• реквизиты клиента обновляются только после подтверждения ответственного сотрудника;
• оплаченный заказ нельзя автоматически вернуть на предыдущий этап.

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

Как обрабатывать нестандартные ситуации

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

До начала разработки стоит разобрать:

• частичную оплату;
• несколько оплат по одному заказу;
• возврат товара;
• отмену после проведения документов;
• изменение цены после согласования;
• объединение дублей;
• удаление клиента или заказа;
• временную недоступность одной из систем;
• повторную отправку данных после ошибки обмена.

Именно такие ситуации чаще всего превращают простую интеграцию в систему из множества несогласованных условий.

Проведите короткую проверку вместе с продажами, бухгалтерией и IT.

Данные о клиенте

• В какой системе создаётся карточка клиента?
• Где хранятся актуальные контакты и реквизиты?
• Кто отвечает за их достоверность?
• Кто может изменять карточку?
• Как обрабатываются дубли?
• Какая система имеет приоритет при расхождении данных?

Цены и скидки

• В какой системе формируется цена?
• Может ли менеджер изменить её вручную?
• Кто согласовывает индивидуальную скидку?
• Может ли бухгалтер изменить согласованную цену?
• Что произойдёт, если цена одновременно изменится в 1С и CRM?
• Фиксируется ли цена после подтверждения или оплаты заказа?

Заказы и документы

• В какой системе создаётся заказ?
• В какой момент он передаётся в 1С?
• Где находится его основная версия?
• Можно ли изменить состав заказа после создания документов?
• Какая система определяет статус заказа?
• Что происходит при отмене или частичной отгрузке?

Оплаты и статусы

• В какой системе фиксируется поступление денег?
• Как информация об оплате передаётся в CRM?
• Что означает статус «оплачено»?
• Как обрабатывается частичная оплата?
• Что происходит при возврате?
• Кто отвечает за разбор расхождений?

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

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

Правильная последовательность выглядит так:

1. Сначала — ответственность.
2. Потом — процессы.
3. Затем — правила обмена.
4. И только потом — IT.

На первом этапе компания определяет владельцев данных.

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

На третьем — фиксирует направления обмена, приоритеты и исключения.

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

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

Попробуйте сегодня задать продажам, бухгалтерии и IT один вопрос:

«Какая система является источником данных о заказе и кто имеет право их менять?»

Если ответы разные, интеграцию нужно начинать не с коннектора.

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

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

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

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

Кто должен определять источник данных при интеграции 1С и Битрикс24?

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

Что делать, если цена товара одновременно изменилась в 1С и в Битрикс24?

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

Можно ли начинать интеграцию 1С и Битрикс24 сразу с выбора коннектора?

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

Чем отличается штатная интеграция 1С и Битрикс24 от кастомной?

Штатные модули работают по ограниченному списку совместимых конфигураций 1С и заранее заданному набору синхронизируемых данных, поэтому не требуют подробного технического задания. Кастомная интеграция гибче, но требует прописанного ТЗ с бизнес-логикой и правилами обработки конфликтов — иначе результат становится непредсказуемым.

Что произойдёт, если не согласовать правила интеграции заранее?

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

Интеграция 1С с Битрикс 24 — Авиант

Нужен ли Битрикс24, если есть 1С? — Авиант

REST API Битрикс24 — официальная документация

Механизмы обмена данными платформы «1С:Предприятие» — официальная документация 1С