Частичные ошибки обмена Битрикс24 и 1С: как найти, дослать и не задвоить записи

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

Что считается частичным обменом Битрикс24 и 1С и где его границы

Частичный обмен — это ситуация, когда синхронизация формально завершилась, но часть объектов не дошла до второй системы или дошла с неполными данными. Часть контрагентов, контактов, счетов или документов появилась, часть осталась только на одной стороне. Внешне это выглядит как «обмен работает», но в CRM не хватает сделок, а в учётной системе — заказов или оплат.

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

Важно сразу разделить два состояния. Первое — объект не создан на принимающей стороне. Второе — объект создан, но с неполными полями: например, счёт есть, а сумма оплаты не подтянулась. Это тоже частичная ошибка.

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

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

Исходные данные и ответственные до первой досылки

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

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

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

Полезно заранее выгрузить срез: список объектов на стороне CRM и список объектов на стороне 1С за один и тот же период. Дальше эти два списка сравниваются по ключу. Разница и есть предмет разбора. Без такого среза любые действия будут наугад.

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

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

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

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

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

Отдельно проверьте, нет ли в CRM уже существующих дублей контрагентов. Если дубль есть, повторная отправка может привязать документ не к той карточке. Разбор дублей — отдельная задача, и ей посвящён материал про дубли контактов и компаний в Битрикс24.

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

Как найти несогласованные записи: сверка по ключу и журналам

Поиск начинается со сверки двух выгрузок по ключу. Возьмите объекты за один период и сопоставьте их. Всё, что есть в CRM и нет в 1С, — кандидат на досылку в сторону учётной системы. Всё, что есть в 1С и нет в CRM, — кандидат на обратную передачу. Записи, которые есть с обеих сторон, но с разными суммами или статусами, — кандидаты на обновление полей.

Дальше смотрите журналы обмена. В Битрикс24 состояние обмена можно увидеть в разделе автоматизации, где отображается предупреждение об ошибке (например, в Коннекторе к 1С). На стороне 1С есть свои журналы и настройки подключения. Журналы показывают, на каком объекте обмен прервался и с каким статусом.

Обратите внимание на типовые статусы. Ошибка авторизации (статус 401) означает, что логин или пароль пользователя, через которого настроен обмен, не совпадают на двух сторонах. Ошибка публикации веб-сервиса (статус 404) означает, что адрес базы или публикация настроены неверно. Ошибка формата адреса означает, что адрес базы указан неполно или с ошибкой (например, пропущен протокол https). Эти состояния лечатся настройкой, а не повторной отправкой.

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

Результат этого шага — список объектов с пометкой: «нет на принимающей стороне», «есть, но поля неполные», «есть, но привязано не к той карточке». Только после этого выбирается действие.

Варианты действий и критерии выбора

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

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

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

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

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

Критерий выбора: сначала причина, потом действие. Если проблема в настройке — исправляем её. Если в данных — исправляем данные. Если в ключе — исправляем ключ. Повторная отправка — последний шаг.

Предметная последовательность действий по шагам

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

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

Шаг третий: сверьте объекты по ключу и составьте список несогласованных записей. Зафиксируйте для каждой записи причину: настройка, данные, ключ или владелец поля.

Шаг четвёртый: устраните причину. Исправьте настройку подключения, дополните ключевые поля, уберите дубль или договоритесь о владельце поля.

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

Шаг шестой: после досылки снова сверьте обе стороны. Убедитесь, что количество объектов совпало и что не появилось новых дублей.

Шаг седьмой: верните автоматический обмен и понаблюдайте один цикл. Если ошибка повторилась на том же объекте, причина не устранена — вернитесь к четвёртому шагу.

Таблица решений: симптом, причина, действие, проверка

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

Как досылать объекты и не создавать дубли

Главное правило досылки: повторяйте только то, чего нет на принимающей стороне. Если объект уже создан, повторная отправка должна обновлять его, а не создавать второй. Это зависит от того, распознаёт ли система ключ.

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

Если объект всё же создался дважды, не удаляйте его сразу. Сначала определите, к какой записи привязаны документы и история. Удаление не той карточки приведёт к потере связей. Сначала перенесите связи, потом удаляйте лишнее.

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

После каждой досылки делайте сверку. Не «на глаз», а по списку ключей. Только так видно, что дубль не появился.

Учебный пример: разбор частичного обмена за один день

Учебный пример. Данные условные, не являются статистикой или реальным кейсом компании.

Входные условия. Компания ведёт продажи в CRM Битрикс24, учёт — в 1С. К CRM подключены две базы: одна для бухгалтерии, одна для склада. За рабочий день менеджеры создали 40 сделок и 25 счетов. Утром следующего дня выяснилось, что в бухгалтерской базе появились только 30 сделок и 18 счетов. Складская база получила все заказы, а бухгалтерская — нет.

Действия. Владелец интеграции остановил расписание обмена и сделал выгрузку сделок и счетов за день. Сверка по ключу «ИНН + название контрагента» показала 10 сделок и 7 счетов, которых нет в бухгалтерской базе. Журнал обмена показал, что часть объектов не прошла из-за неполного адреса базы в настройке подключения. У двух контрагентов ИНН был не заполнен, поэтому ключ не сработал.

Что сделали по шагам. Исправили адрес базы в настройке. Заполнили ИНН у двух контрагентов. Проверили, что в бухгалтерской базе нет записей с этими ключами. Дослали 10 сделок и 7 счетов. После досылки сверили обе стороны по списку ключей.

Наблюдаемый результат. Количество сделок и счетов в бухгалтерской базе совпало с CRM. Новых дублей контрагентов не появилось. Автоматический обмен вернули и понаблюдали один цикл — ошибка не повторилась.

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

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

Чек-лист приёмки после разбора частичного обмена

• Определён период и список объектов, которые должны были пройти обмен
• Зафиксировано правило ключа сопоставления и проверена его уникальность
• Определён владелец каждого объекта и каждого спорного поля
• Сделана выгрузка или копия затронутых данных до изменений
• Найдены все несогласованные записи и указана причина по каждой
• Причина устранена до повторной отправки, а не после
• Досылались только объекты, отсутствующие на принимающей стороне
• После досылки выполнена сверка по ключу на обеих сторонах
• Проверено отсутствие новых дублей контрагентов и документов
• Автоматический обмен возвращён и проверен на одном цикле
• Зафиксировано, кто отвечает за повторный разбор при повторе ошибки

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

Типичная ошибка — начинать с повторной отправки. Если причина в настройке или ключе, повтор только создаст дубли или снова ничего не передаст. Вторая ошибка — досылать объекты, которые уже есть, но с неполными полями. Это не досылка, а обновление, и делать его нужно иначе.

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

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

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