При настройке двустороннего обмена между 1С:Управление торговлей (УТ) и 1С:Бухгалтерия предприятия (БП) часто возникает критическая ситуация: данные одного контрагента в базе заменяются данными другого только потому, что у них совпадают наименования. Это происходит даже в тех случаях, когда ИНН и КПП у организаций различаются. В некоторых случаях для корректной передачи данных требуется предварительная регистрация объектов для обмена по конкретной организации, чтобы сузить выборку. Проанализируем механизмы работы синхронизации, выясним причину такого поведения системы и разберем пошаговые инструкции по устранению этой ошибки.
Для начала разберем, как именно система 1С понимает, что контрагент в УТ и контрагент в БП — это один и тот же объект. Процесс сопоставления происходит в несколько этапов. Если на одном из этапов соответствие найдено, поиск прекращается, и система устанавливает жесткую связь между объектами.
Рассмотрим последовательность поиска, которая заложена в типовые правила обмена (особенно в формате Enterprise Data):
Соответствия объектов информационных баз. Если объекты ранее уже были сопоставлены, система просто обновляет данные по этой ссылке, не проверяя ИНН или наименование.Проблема заключается в логике "ИЛИ". Посмотрим на ситуацию: в БП создан новый контрагент с тем же названием, что уже есть в УТ, но с другими реквизитами. При обмене система не находит совпадений по ИНН, переходит к следующему правилу — поиску по наименованию — и находит "тезку". С этого момента система считает, что это один и тот же контрагент, и принудительно перезаписывает ИНН и КПП в УТ данными, пришедшими из БП.
Выясним, где хранится информация о том, что объекты связаны. Эта "память" обмена находится в регистре сведений Соответствия объектов информационных баз. Если один раз произошло ошибочное сопоставление (например, по наименованию), то даже после исправления ИНН вручную, при следующем обмене данные снова будут затерты, так как связь по GUID уже зафиксирована в этом регистре.
Чтобы разорвать эту связь, выполним следующие действия:
Функции для технического специалиста (или «Все функции»).Соответствия объектов информационных баз.СправочникСсылка.Контрагенты и найдем строку, где указан наш проблемный контрагент.Многие пользователи спрашивают, можно ли сделать так, чтобы система каждый раз спрашивала подтверждение перед сопоставлением. Разберем, как вызвать окно сопоставления вручную, чтобы не допустить автоматического затирания.
В типовых конфигурациях на платформе 1С:Предприятие 8.3 предусмотрен специальный инструмент. Рассмотрим алгоритм его запуска:
Администрирование — Синхронизация данных.Настройки синхронизации данных.Синхронизировать с раскрывающимся меню, где выберем «Синхронизация с дополнительными параметрами».Если вы являетесь разработчиком и хотите изменить саму логику обмена, чтобы поиск по наименованию никогда не приводил к перезаписи ИНН, проанализируем код правил конвертации. В классических правилах (КД 2.0) это настраивается в обработчике ПоляПоиска.
Например, если вы все еще используете правила обмена для УТ 10.3 и БП 3.0, вы можете вручную скорректировать алгоритмы сопоставления в файле правил.
Посмотрим на пример кода, который можно использовать для отмены поиска по наименованию, если ИНН не заполнен или не совпал:
Если НомерВариантаПоиска = 2 Тогда
// Если поиск по ИНН/КПП не дал результатов,
// мы можем прервать дальнейший поиск по наименованию
Отказ = Истина;
КонецЕсли;
В современных обменах через Enterprise Data логика поиска часто жестко зашита в модуле менеджера плана обмена. В этом случае рекомендуется использовать расширение для корректировки алгоритма в процедуре ПриПоискеОбъекта.
Чтобы минимизировать риски при двустороннем обмене, проанализируем следующие рекомендации:
Подведем итог. Если вы столкнулись с затиранием данных:
Соответствия объектов информационных баз для пострадавших контрагентов.Помните, что двусторонний обмен — это всегда риск конфликта данных. Регулярный аудит справочников и использование инструментов сопоставления помогут сохранить целостность вашей информационной системы.