Битрикс24 и 1С: три схемы обмена и когда какую брать

Интеграция Битрикс24 и 1С собирается одной из трёх схем: вендорский коннектор обмена, шина между системами или точечный REST «по запросу». Коннектор берут, когда справочники типовые и можно прожить с его правилами. Шину — когда систем больше двух. REST — когда CRM не должна стать зеркалом учёта. «Поставить коннектор и забыть» ломается на дублях и кастомной 1С.

Три контура обмена, не одна галочка

Продажи хотят видеть в сделке долг, лимит отсрочки и «есть ли товар». Учёт хочет, чтобы CRM не плодила контрагентов и не переписывала проведенные документы. Это разные правды. Схема обмена — договор, какая система в каком поле главная. Без договора коннектор просто быстрее разнесёт мусор.

Схема 1. Вендорский коннектор 1С ↔ Битрикс24

Модуль обмена закрывает типовой набор: контрагенты, номенклатура, заказы, счета. Его ставят, когда 1С относительно типовая (УТ, УНФ, похожие контуры), а CRM не требует экзотики. Плюс — не писать транспорт с нуля. Минус — вы живёте правилами модуля: ключ поиска контрагента, направление, что считается заказом.

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

Ещё коннектор провоцирует полное зеркало. Кажется полезным тащить все реализации за три года в сделки. Получаете 40 000 карточек, воронка мертва, менеджеры ищут клиента поиском пять секунд. История отгрузок часто нужна как справка по запросу, а не как 40 000 сделок.

Схема 2. Шина: 1С, сайт, WMS, CRM

Шина имеет смысл, когда Битрикс24 — не единственный потребитель 1С. Сайт, склад, курьерка, ещё одна база. Тогда 1С публикует событие «контрагент изменён», шина мапит поля, CRM забирает свой кусок. Прямой «каждый с каждым» через пять коннекторов разъезжается после первого обновления.

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

Схема 3. Точечный REST: спросили — ответили

CRM показывает долг и остаток, когда менеджер открыл карточку. Не ночью зеркалит всю базу. Заказ в 1С создаётся в момент «выиграли», не на каждой смене стадии. Это схема «on-demand»: меньше дублей, меньше гонки обновлений, меньше сюрпризов после регламентного обмена в 3:00.

Минус — надо проектировать методы. «Остаток по SKU», «долг по договору», «создать заказ». Если 1С-команда не отдаёт API, UI в CRM можно собрать на демо-данных, а живой метод принять отдельным критерием. Нельзя обещать двусторонний обмен всех сущностей в этапе «отчёт руководителю».

Точечный контур хорошо стыкуется с запуском с MVP: в первую очередь менеджер видит долг и запрет отгрузки, а не «красивый полный клон 1С». Полный клон почти никто не тянет дисциплиной.

Как выбрать схему: признаки, не вкусовщина

• Типовая 1С, один юрлиц, нужны контрагенты и заказы в обе стороны — смотрите коннектор, но сразу задайте ключ ИНН + КПП + тип.
• Несколько систем вокруг учёта — шина, иначе через год пять хрупких точек.
• Нужны долг, лимит, остаток в карточке, без зеркала документов — REST по запросу.
• 1С сильно кастомная, коннектор «почти подходит» — не насилуйте модуль, режьте scope до методов.
• Нет владельца 1С на стороне клиента — любая схема встанет. Сначала человек, потом транспорт.

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

Что считать источником правды

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

Грязная база до обмена гарантирует грязный обмен. Если компании живут в таблице «как получилось», сначала чистка и отказ от двойного учёта, потом коннектор. Иначе вы автоматизируете хаос быстрее, чем вручную.

Что не делать

• Не ставить коннектор в пятницу вечером без ключа поиска и ответственного за дубли.
• Не зеркалить все документы учёта в сделки «для полноты».
• Не обещать обмен «всего» за одну итерацию, если 1С с доработками.
• Не делать CRM главным редактором ИНН и расчётных счетов.
• Не путать вендорский коннектор 1С с любым «коннектором WhatsApp» — это разные продукты и разные риски.

В NAVIPOINT схему 1С не выбирают из каталога «потому что модуль есть». Смотрим документы, филиалы, кто главнее в поле. Работы по CRM-стороне — в услугах внедрения. Вилка и состав — на странице стоимости. Модуль 1С часто идёт отдельной сметой с 1С-партнёром, не внутри «настроим Битрикс».

Какие объекты тащить в первую итерацию, какие не трогать

Берите в пилот то, из-за чего менеджер сегодня орёт в бухгалтерию. Обычно это контрагент, договор или лимит, долг, наличие по ключевым SKU, создание заказа в момент выигрыша. Не берите в пилот все реализации за пять лет, серийные номера, производственные этапы и «на всякий случай всю номенклатуру с картинками». Картинки подождут. Дубль на 15 000 SKU не подождёт: он приедет в первую ночь.

Направления обмена запишите стрелками. Контрагент: 1С → CRM, править ИНН только в учёте. Контактное лицо: чаще CRM → как комментарий или отдельный справочник, потому что снабженец живёт у продаж, не в 1С. Заказ: CRM → 1С в одном статусе, обратно — номер документа и проведение, не десять промежуточных статусов «как в воронке». Чем длиннее зеркало статусов, тем чаще оно врёт.

Облачная 1С и коробка ведут себя по-разному на регламентных заданиях и доступе к API. Облако может резать частоту запросов и не любить «опрос каждую минуту». Коробка на чужом сервере «у админа Васи» падает в обновлении без уведомления CRM. В договоре на обмен должен быть человек 1С с телефоном, не «модуль сам». Иначе в пятницу вечером чинит тот, кто ближе к почте, а это обычно интегратор CRM, который базу учёта не ведёт.

Пилот на двадцати карточках, не на всей стране

1. Выберите 20 живых контрагентов: с филиалом, без ИНН в CRM, с двумя договорами, с «просто ИП».
2. Прогоните обмен в одну сторону. Сверьте имена, ИНН, телефоны, не «галочка успех в журнале».
3. Смените телефон в 1С, дождитесь обмена, посмотрите, не родился ли дубль.
4. Создайте тестовый заказ из выигранной сделки. Найдите его в 1С. Сверьте сумму и юрлицо.
5. Сломайте нарочно: закройте доступ, повторите. Посмотрите, кто узнает, что обмен встал — журнал, письмо, тишина.

Тишина — самый дорогой результат. Обмен «зелёный», а поля пустые, потому что маппинг смотрит не туда. Журнал модуля врёт оптимизмом. Сверка — глазами по карточкам, плюс простой отчёт: контрагенты без ИНН, ИНН без КПП где КПП обязателен, сделки без связанного заказа после стадии «оплата». Если отчёта нет в первую неделю, вы узнаете о дублях от клиента, которому выставили два счёта.

Гонка обновлений. Менеджер правил название в CRM, бухгалтер — в 1С, ночной обмен взял «чья запись новее» как получится. Без поля «хозяин» вы получите войну. Хозяин юрлица — учёт. Хозяин стадии и следующего звонка — CRM. Хозяин долга — 1С, даже если цифра в сделке красивее. Красивая цифра в сделке, которая не бьётся с актом, разрушает доверие быстрее, чем отсутствие цифры.

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

Разделение ролей в смете. Модуль и доработка 1С — зона 1С-партнёра. Поля, роботы, права, обучение продаж — зона CRM. Если всё засунуть в одну фразу «интеграция под ключ», через месяц некому чинить ключ поиска. На консультации NAVIPOINT это рисуем двумя блоками. Без прайса в статье: объём зависит от кастома учёта и от того, зеркало вам нужно или справка.

Типичные поломки через месяц «успешного» обмена

Номенклатура разъехалась единицами: в 1С упаковка, в CRM штука, менеджер обещает остаток, которого нет. Резерв в учёте есть, в карточке нет — продали дважды. Договор в 1С закрыли, в CRM лимит живой — отгрузили должнику. Это не «коннектор тупит». Это не те поля или не та частота. Чинят картой полей и регламентом, не перезапуском модуля по ночам.

Обновление 1С сняло расширение обмена. Обновление Битрикс24 поменяло поле. Владелец должен прогнать пилот из пяти карточек после каждого обновления. Звучит скучно. Дешевле скуки, чем неделя двойных счетов. Календарь «после обновления учёта — сверка» пишут в регламент, не в чат «напомни пожалуйста».

Отчёт «всё выгрузилось» врёт, если смотреть только счётчик. Смотрите ошибки: пустой ИНН, запрещённый символ, контрагент-помечен на удаление. Журнал ошибок должен падать человеку, не лежать во вкладке, которую открывают раз в квартал. Ошибка без владельца — это успешный обмен в презентации и помойка в базе.

Когда выбирать REST вместо коннектора задним числом. Признак: вы уже выключили половину объектов модуля, потому что они мешают, и оставили долг плюс заказ. Значит, модуль был лишней рамой. Честно перейдите на методы. Держать мёртвый коннектор «вдруг пригодится полное зеркало» — платить сложностью каждый месяц.

Склад и резерв отдельно от «остатка в карточке». Менеджер видит свободный остаток или «всё, что числится». Разница — сорванная отгрузка. Подпишите в справке, какая цифра на экране. Если 1С не отдаёт свободный, не рисуйте зелёную цифру «как будто свободно». Лучше серое «уточнить на складе», чем ложная уверенность.

Несколько баз 1С. Филиал ведёт свою, центр — свою. Коннектор «в одну CRM» без префикса организации смешает справочники. Либо разные порталы (редко нужно), либо поле организации и ключ с префиксом. Это решение до пилота, не после первой ночи, когда в CRM уже две «Ромашки» с разными учётными политиками.

Документы печати. Счёт из CRM для клиента и счёт из 1С для учёта — разные бумаги, если вы не договорились. Либо CRM печатает черновик, а 1С — оригинал, либо сразу оригинал из учёта по кнопке в сделке. Два оригинала с разными суммами — классика скандала. Выберите одну печатную форму-истину до обучения менеджеров.

Коротко по вопросам

Какой коннектор «правильный»?

Тот, чей ключ поиска совпадает с вашей базой. Типовой модуль не плох. Плох модуль на кастомной 1С без карты полей.

Можно ли обойтись без обмена?

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

Почему после обмена остатки «плывут»?

Чаще разные склады, резервы, единицы измерения или задержка регламентного задания. Реже — «Битрикс врёт». Смотрите, какой запрос считается истиной.

Нужна ли шина маленькой компании?

Обычно нет. Две системы — коннектор или REST. Шина окупается на третьей системе.

С чего начать, если боитесь дублей?

С правила создания карточки и ключа ИНН/КПП. Потом пилот на 20 контрагентах, не на всей базе.

Кто внедряет?

Иван Остривной, NAVIPOINT — партнёр Битрикс24. На консультации разбираем ваш контур и очередь, без обещаний «подключим всё за вечер».

Нужен разбор схемы обмена 1С и Битрикс24 на вашем портале — запишитесь на консультацию. Схему и объём работ называем после фактов: какие каналы уже живые, какой тариф, кто отвечает клиенту. Прайса «из статьи» нет.