Антон Дегтярёвконнектор 1с и битрикс24 или своя интеграция: как выбрать до старта работ
Штатный коннектор к 1С закрывает задачу примерно в половине проектов, куда меня зовут. Неприятность в том, что понимают это обычно не на старте, а через две-три недели настройки — когда суммы в CRM впервые разошлись с суммами в 1С и стало ясно, что часть данных коннектор просто не видит. Ниже — пять признаков, по которым такой исход виден заранее, за один разговор с бухгалтером и 20 минут в конфигураторе.
о чём на самом деле идёт спор
Когда клиент спрашивает «нам хватит коннектора или нужна разработка», он думает, что спрашивает про софт. Фактически вопрос звучит иначе: насколько ваш учёт в 1С отличается от того, каким его задумал вендор. Коннектор — это готовый набор правил обмена под типовую конфигурацию. Чем дальше ваша база от типовой, тем меньше этих правил попадает в цель.
Поэтому оценивать надо не Битрикс24 и не сам коннектор, а вашу 1С. Я на первой встрече прошу открыть конфигуратор и посмотреть одну вещь — стоит ли на конфигурации замок. Снятая с поддержки, доработанная база — это сразу другой разговор о сроках и деньгах, независимо от того, что написано в описании коннектора.
Обзор всех способов обмена — штатный модуль, коннектор, готовые сервисы, разработка под задачу — я делал отдельно в статье про варианты обмена 1С и Битрикс24. Здесь разбираю только развилку между готовым решением и доработкой: как понять, на какую сторону вы попадаете, до того как заплатите за настройку.
что коннектор умеет по документации вендора
Начнём с фактов, а не с ощущений. По документации Битрикс24 коннектор работает с платформой 1С:Предприятие 8 — конфигурации на платформе 7 не поддерживаются вообще. Из типовых конфигураций заявлены 1С:Бухгалтерия, 1С:Управление торговлей и 1С:УНФ, на актуальных релизах.
Набор синхронизируемых сущностей у каждой конфигурации свой: с Бухгалтерией это счета, с Управлением торговлей — связка «сделка в Битрикс24 ↔ заказ в 1С», с УНФ — и счета, и сделки. Обмен работает в трёх режимах: в реальном времени, вручную по кнопке и по расписанию. Модуль ставится в 1С расширением, то есть менять типовую конфигурацию не требуется.
Это важная деталь: раз коннектор ставится расширением, он не ломает обновляемость базы. Именно поэтому я всегда начинаю с попытки уложиться в коннектор — сохранённая типовая конфигурация экономит клиенту деньги на каждом будущем обновлении 1С, а самописный обмен эту экономию съедает.
тест на 20 минут — пять вопросов до начала работ
Прежде чем называть цену, я задаю пять вопросов. Первый: конфигурация типовая или доработанная, снята ли с поддержки. Второй: сколько юрлиц и ведётся ли по ним раздельный учёт. Третий: какими документами реально живёт компания — хватает ли заказа и счёта или есть свои виды документов.
Четвёртый: какой объём данных и с какой задержкой он должен попадать в CRM — раз в сутки, раз в час или мгновенно. Пятый: по какому реквизиту вы отличаете одного контрагента от другого — ИНН, внутренний код, название.
Если по всем пяти ответы «типовая, одно юрлицо, заказы и счета, раз в час достаточно, ИНН» — коннектор закроет задачу, и это те самые 40-70 тысяч рублей и 3-5 рабочих дней типового обмена. Каждый ответ, который выбивается из этого набора, добавляет к проекту либо доработку, либо ограничение, о котором клиент должен узнать заранее. Разбираю их по одному ниже.
сигнал 1 — доработанная конфигурация
Самый частый сигнал. Конфигурация формально называется «Управление торговлей», но за годы работы в неё добавили десяток реквизитов: собственные виды скидок, признак склада отгрузки, поле для менеджера-куратора. Коннектор про эти реквизиты ничего не знает — он умеет отдавать типовые поля типовых документов.
Как это выглядит на практике: обмен запускается, заказы приезжают, а сумма в сделке не совпадает с суммой в 1С, потому что скидка лежит в добавленном реквизите и в стандартный обмен не попадает. Это самый частый повод для звонка «у нас всё настроили, но цифры не сходятся» — и половина моих проектов по починке обмена начинается именно с него.
Развилка здесь такая. Если добавленных полей два-три и они нужны в CRM справочно — дешевле дописать их передачу точечно, оставив коннектор основой. Если доработок много и они меняют саму логику расчёта документа — коннектор становится обузой: вы платите за него и всё равно пишете свою логику поверх.
сигнал 2 — несколько юрлиц и раздельный учёт
Второй по частоте случай, особенно в опте и производстве. Компания работает через два-три юрлица, у каждого своя база или своя область в общей базе, а в Битрикс24 отдел продаж один и хочет видеть всех клиентов вместе. Штатная логика обмена рассчитана на прямую связку одной базы с одним порталом.
Вопросы, которые надо решить до настройки, а не после: как определяется, в какое юрлицо уходит сделка, что происходит с контрагентом, который покупает у двух юрлиц одновременно, и как считается общая выручка по клиенту. Ни один из этих вопросов не решается настройкой коннектора — это правила, которые надо описать и запрограммировать.
На таких проектах я обычно делаю связку из коннектора на каждую базу плюс отдельный слой правил на стороне Битрикс24, который определяет юрлицо по типу товара или региону. Сроки при этом сдвигаются с недели к двум-трём, а бюджет уходит в диапазон расширенного обмена — от 90 тысяч рублей.
сигнал 3 — обмен не заказами и счетами
Коннектор мыслит парой «сделка ↔ заказ» и счетами. Если ваш реальный процесс живёт другими документами — актами выполненных работ, заявками на производство, договорами с графиком платежей, отгрузками по частям — типовой обмен эти сущности не переносит, потому что их нет в его модели.
Показательный пример из практики: строительная компания, где деньги приходят частями по графику, а в CRM нужно видеть, сколько по сделке уже оплачено. В связке «сделка ↔ заказ» этого нет — нужен обмен документами оплат и своя логика, которая складывает их в поле сделки. Это уже разработка, но небольшая, на несколько дней.
Отдельная история — товары, характеристики и остатки: их обмен подчиняется своим правилам и ломается не там, где ждут. Я разбирал это подробно в статье про обмен товарами и остатками между 1С и Битрикс24 — если у вас интернет-магазин или опт, читать её надо до подписания сметы.
сигнал 4 — скорость и объём
Режим реального времени в описании коннектора не означает, что любая база будет обмениваться мгновенно. Скорость упирается в две вещи: производительность вашей 1С и лимиты Битрикс24 на количество обращений к API. При обмене в несколько тысяч документов в сутки разница между «по расписанию» и «в реальном времени» становится принципиальной.
Практическое правило, которым я пользуюсь: если документов до нескольких сотен в сутки — берите обмен по расписанию раз в час, этого хватает и это надёжнее. Реальное время нужно там, где менеджер физически ждёт результата в разговоре с клиентом: проверить оплату, увидеть отгрузку, подтвердить наличие.
Ошибка, которую вижу регулярно, — включить мгновенный обмен «на всякий случай» по всем сущностям сразу. Нагрузка растёт, обмен начинает подтормаживать на пиках, и вместо ускорения компания получает очередь и расхождения. Что ещё ломается в обмене и как это чинить, я собрал в статье про типовые ошибки обмена 1С и Битрикс24.
сигнал 5 — по чему сопоставляются контрагенты
Любой обмен упирается в вопрос, как система понимает, что контрагент в 1С и компания в Битрикс24 — это один и тот же клиент. Если ответ «по ИНН» и ИНН заполнен у всех — задача решается штатно. Если по названию — готовьтесь к дублям: «ООО Ромашка», «Ромашка ООО» и «Ромашка» для системы три разные компании.
Показательная цифра с аудитов: в базах, которые вели без правил сопоставления, дубли составляют 10-20% карточек. После запуска обмена они удваиваются, потому что каждая несопоставленная запись из 1С создаёт новую компанию в CRM. Чистить это потом дороже, чем договориться о ключе на старте.
Поэтому в порядок работ я всегда ставлю чистку справочника контрагентов до первого обмена, а не после. Механику чистки и выбор ключа сопоставления разбирал отдельно — дубли контрагентов при обмене 1С и Битрикс24. Пропустить этот шаг — гарантированно вернуться к нему через месяц, но уже с удвоенным объёмом.
сколько стоит каждый путь
Три сценария по деньгам и срокам, в тех цифрах, по которым я работаю. Типовой обмен на коннекторе: 40-70 тысяч рублей и 3-5 рабочих дней настройки, плюс лицензия коннектора отдельной строкой — от 30 тысяч. Подходит, если тест из пяти вопросов пройден без замечаний.
Расширенный обмен — коннектор плюс доработка под ваши поля и документы: от 90 тысяч рублей и 2-3 недели. Сюда попадает большинство проектов с доработанной конфигурацией или несколькими юрлицами. Полностью своя интеграция через REST API: от 100 тысяч и 3-4 недели с учётом тестирования, плюс сопровождающий разработчик дальше.
Скрытая строка, о которой забывают, — поддержка после запуска. Обновилась 1С, изменился формат документа, добавили новый вид скидки: любой самописный обмен требует правки. Я считаю такие работы почасово, по 3 000 рублей в час, и закладываю несколько часов в квартал даже на стабильном обмене. Полный разбор сметы — в статье про стоимость интеграции 1С и Битрикс24.
гибрид, который я выбираю чаще всего
Практический вывод из полутора десятков проектов: чистая развилка «коннектор или своя разработка» встречается редко. В большинстве случаев рабочий вариант — коннектор как основа плюс точечная доработка на 20-30% объёма, там, где типовых правил не хватает.
Логика простая. Коннектор берёт на себя рутину, которую не хочется писать заново: контрагенты, счета, заказы, статусы оплат. Доработка закрывает ровно то, что специфично для вашего учёта — передачу добавленных реквизитов, разбор своих документов, правило определения юрлица. Такой обмен переживает обновления 1С заметно лучше полностью самописного.
Отказываюсь от коннектора я только в двух ситуациях: конфигурация самописная и от типовой не осталось почти ничего, либо обмен идёт не с 1С напрямую, а через промежуточную систему. Для тяжёлых конфигураций разговор отдельный — про особенности связки с УПП я писал в статье про обмен между 1С:УПП и Битрикс24.
порядок запуска, при котором не придётся переделывать
Шаг первый — тест из пяти вопросов и решение по схеме до сметы. Шаг второй — чистка справочника контрагентов в 1С и выбор ключа сопоставления. Шаг третий — обмен в одну сторону на копии базы: сначала справочники, потом документы, никогда всё сразу.
Шаг четвёртый — сверка контрольной группы: беру 20-30 реальных документов за прошлый месяц и вручную сравниваю суммы, контрагентов и даты в 1С и в CRM. Расхождение хотя бы в одном — разбираемся до включения двустороннего режима, а не после. Шаг пятый — включение двустороннего обмена и наблюдение две недели с ежедневной проверкой расхождений.
Этот порядок занимает на 2-3 дня больше, чем «настроить и запустить», и экономит неделю разбирательств потом. Главное правило, которое я повторяю на каждом проекте: обмен тестируется на реальных документах прошлого месяца, а не на тестовых контрагентах с суммой 100 рублей — тестовый контрагент никогда не покажет, что скидка не доехала.