Несколько юрлиц и филиалов в обмене Битрикс24 и 1С: как различать контрагентов и сделки

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

Что именно нужно различать: контрагент, филиал, юрлицо

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

Возможны три разные сущности, которые заказчик часто называет одним словом «контрагент». Первая — юридическое лицо с собственным ИНН, КПП и реквизитами. Вторая — филиал или обособленное подразделение внутри одного юрлица: ИНН тот же, КПП и адрес другие. Третья — торговая точка или направление, которое вообще не является отдельным юрлицом, но ведёт свои продажи и хочет видеть только свои сделки.

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

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

Исходные данные и ответственные за сопоставление

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

Назначьте владельца. У поля-различителя должен быть один ответственный человек, который решает спорные случаи: например, руководитель отдела продаж или администратор CRM. У самого объекта тоже нужен владелец — тот, кто отвечает за корректность карточки контрагента. Когда владельцев несколько и они не согласованы, обмен воспроизводит конфликт, а не решает его.

Определите, какие объекты вообще участвуют в обмене. Обычно это контрагенты, контакты, сделки, счета и связанные документы. Если каталог товаров или склад участвует в другой схеме, не смешивайте её с этой задачей: у неё свои ключи и свои правила. Границы этой работы — CRM Битрикс24 и учётная система 1С, а не обмен каталога сайта.

Зафиксируйте, где хранится истина по каждому полю. Реквизиты юрлица логично вести в 1С, а ответственного менеджера и стадию сделки — в CRM. Если истина не назначена, при обмене поля будут перетирать друг друга, и вы получите «плавающие» реквизиты в счетах. Это одна из самых частых причин, по которой заказчик считает обмен сломанным, хотя формально он работает.

Почему ИНН не всегда единственный ключ

ИНН уникален для юридического лица, но не для филиала и не для торговой точки. У одного юрлица может быть несколько обособленных подразделений с одинаковым ИНН и разными КПП. Если обмен сопоставляет записи только по ИНН, все филиалы схлопнутся в одну карточку, и сделки разных офисов смешаются.

Вторая причина — исторические данные. В CRM могли годами заводить контрагентов вручную, и у одной и той же организации появилось несколько карточек с опечатками в названии или без ИНН вовсе. При первом обмене такие записи не найдут пару и создадут дубли. Прежде чем включать синхронизацию, стоит разобраться с дублями: как их находить и объединять, не теряя историю, разобрано в материале про Дубли контактов и компаний в Битрикс24: как найти, объединить и сохранить историю.

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

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

Матрица сценариев: один ИНН — N филиалов и N юрлиц

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

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

Последовательность действий по настройке обмена

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

Шаг первый — привести справочники к единому виду. Уберите очевидные дубли, заполните ИНН и КПП там, где их нет, приведите названия к понятному виду. Это ручная работа, но она определяет качество всей дальнейшей автоматики.

Шаг второй — определить поля-различители в CRM. Обычно это «Юрлицо», «Филиал» и, при необходимости, «Точка продаж». Поля должны быть обязательными для заполнения в тех воронках, где это важно, иначе менеджер их пропустит.

Шаг третий — настроить сопоставление. Проверьте, как именно ваша схема обмена определяет пару «запись в 1С — карточка в CRM». Если встроенных правил не хватает, это повод для отдельной задачи на доработку логики сопоставления, а не для ручной правки каждой сделки (что нарушает целостность данных). Общая логика такой работы описана в материале про интеграцию Битрикс24 с 1С.

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

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

Как размечать контрагентов, сделки и реквизиты

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

Для контрагента правило простое: одна карточка — одно юрлицо или один филиал, в зависимости от выбранного сценария. В карточке обязательны ИНН, КПП и значение поля-различителя. Если контрагент — торговая точка без отдельного юрлица, вместо ИНН используется внутренний код, согласованный с учётной системой.

Для сделки правило сложнее. Сделка должна быть привязана к конкретному контрагенту (юрлицу или филиалу), а не к «группе компаний». Если клиент покупает у двух юрлиц, это две сделки, а не одна с переключателем. Иначе счёт и документы будет невозможно корректно сформировать. Логика работы со счетами и документами подробно разобрана в статье про Автоматизация счетов в Битрикс24: как настроить генерацию документов.

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

Матрица проверок перед включением обмена

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

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

Учебный пример: группа компаний с двумя юрлицами и филиалами

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

Входные условия: обмен настроен по ИНН, поля-различители не заполняются, реквизиты правятся вручную в карточке. Наблюдаемый результат до исправления: сделки обоих филиалов «Пример-Опт» попадают в одну карточку, счёт иногда формируется с реквизитами «Пример-Розница», история продаж по филиалам не разделяется.

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

Проверка. Создали по одной тестовой сделке на каждый филиал и на второе юрлицо. Убедились, что сделки не склеиваются, счета формируются с реквизитами нужного юрлица, сотрудник филиала не видит чужие сделки. После успешной проверки включили обмен на ограниченном периоде и сверили результат с учётной системой. Данные примера учебные и не являются реальной статистикой или кейсом компании.

Чек-лист приёмки обмена с несколькими юрлицами

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

• Определена единица учёта: что считается отдельным контрагентом в CRM и в 1С.
• Составлен перечень юрлиц с ИНН и КПП и перечень филиалов с привязкой к юрлицу.
• Назначен владелец поля-различителя и владелец карточки контрагента.
• Ключ связи не сводится к одному ИНН: учтены КПП и код подразделения там, где это нужно.
• Поля-различители заполнены и обязательны для новых карточек.
• Дубли контрагентов разобраны до включения обмена.
• Реквизиты юрлица не правятся вручную в CRM.
• Права доступа настроены отдельно от логики обмена.
• Проверки выполнены на тестовом контуре, есть план возврата.
• Обмен включён на ограниченном периоде, результат сверен с учётной системой.

Ограничения, типичные ошибки и следующий шаг

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

Типичные ошибки повторяются. Первая — ключ только по ИНН, из-за чего филиалы склеиваются. Вторая — ручная правка реквизитов в CRM, из-за чего документы уходят с чужими данными. Третья — отсутствие владельца поля, из-за чего спорные случаи решаются каждый раз заново. Четвёртая — включение обмена на рабочих данных без тестового контура и плана возврата.

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