При настройке типовой синхронизации между 1С:Управление торговлей 11.5 и 1С:Бухгалтерия предприятия 3.0 пользователи часто сталкиваются с проблемой некорректного сопоставления договоров — для её решения пригодятся доработанные правила обмена EnterpriseData для УТ 11 и БП 3.0. Особенно остро это проявляется в операциях Интеркампани (передача товаров между организациями). В УТ 11 это документы передачи, где фигурирует договор между двумя собственными организациями, а в БП 3.0 они трансформируются в документы поступления или реализации, где одна из организаций выступает в роли контрагента. В данной статье мы разберем, почему система может игнорировать существующие привязки и как заставить обмен работать корректно.
Для начала проанализируем ключевое отличие современного обмена через универсальный формат от старых технологий. Если в КД 2.0 основным инструментом сопоставления был регистр сведений СоответствияОбъектовИнформационныхБаз, то в EnterpriseData (КД 3.0) используется регистр ПубличныеИдентификаторыСинхронизируемыхОбъектов.
Рассмотрим стандартную стратегию поиска объекта в приемнике при поступлении данных:
ПубличныеИдентификаторыСинхронизируемыхОбъектов. Если соответствие найдено и ссылка на объект в базе актуальна, система берет этот объект.Если вы обнаружили, что в регистре идентификаторов связь прописана верно, но в документе все равно появляется "чужой" договор или создается дубль, значит, проблема кроется в логике валидации владельца или в специфике работы модуля менеджера обмена — выявить расхождения в договорах поможет сверка взаиморасчетов по счетам 60 и 62 между БП 3.0 и УТ 11.5.
Выясним причину, по которой GUID в регистре может игнорироваться. Справочник ДоговорыКонтрагентов является подчиненным справочнику Контрагенты. В архитектуре 1С при поиске подчиненного объекта система всегда проверяет его владельца.
Рассмотрим ситуацию: в УТ 11 организация "Альфа" передает товар организации "Бета". В БП 3.0 это превращается в покупку "Бетой" у контрагента "Альфа". Если по какой-то причине организация "Альфа" в БП сопоставлена не с тем контрагентом, который указан в качестве владельца договора в регистре идентификаторов, система отбросит найденную ссылку как "невалидную" и попытается найти другой договор у правильного контрагента или создаст новый.
В отличие от КД 2.0, правила здесь не хранятся во внешних XML-файлах. Разберем, в каких модулях сосредоточена логика. Основная работа по преобразованию данных в БП 3.0 происходит в общем модуле МенеджерОбменаЧерезУниверсальныйФормат.
Проанализируем структуру поиска. Вам необходимо найти функции, отвечающие за обработку справочника договоров. Обычно это процедуры, начинающиеся с префикса ППО_Справочник_ДоговорыКонтрагентов_....
В частности, за чтение и поиск отвечает процедура ППО_Справочник_ДоговорыКонтрагентов_ПриЧтенииДанныхXDTO. В ней жестко прописаны приоритеты полей поиска:
Рассмотрим пошагово, как выявить место сбоя, если отладчик кажется слишком сложным инструментом на первом этапе.
Для начала проанализируем, что именно УТ 11 отправляет в БП. Настройте синхронизацию через локальный или сетевой каталог, чтобы иметь доступ к файлу обмена. Для контроля выгрузки документов и исправления ошибок после обмена подойдёт поиск расхождений между УТ и БП с повторной регистрацией.
<CatalogObject.ДоговорыКонтрагентов>, соответствующий вашему проблемному договору.Ref. Это и есть GUID, который будет искаться в БП в регистре публичных идентификаторов.Ref с тем, что записан в БП в регистре ПубличныеИдентификаторыСинхронизируемыхОбъектов. Если они разные — проблема в УТ (договор был перевыбран или пересоздан).Если GUID совпадают, но договор в БП все равно "слетает", переходим к отладке в БП 3.0. Поставим точку останова в модуле менеджера обмена.
// В модуле МенеджерОбменаЧерезУниверсальныйФормат
// Найдите фрагмент, где происходит поиск договора
Процедура ППО_Справочник_ДоговорыКонтрагентов_ПриЧтенииДанныхXDTO(ДанныеXDTO, КомпонентыОбмена)
// Установите точку останова здесь
// Проверьте значения переменных:
// ДанныеXDTO.Владелец - правильно ли определился контрагент?
// ДанныеXDTO.Организация - совпадает ли с организацией в БП?
КонецПроцедуры
Частая причина сбоев в Интеркампани — наличие дублей контрагентов, созданных для собственных организаций — решить проблему поможет обработка устранения дублей в двух синхронизированных базах. Проверьте, нет ли в БП двух карточек контрагентов с одинаковым ИНН, одна из которых привязана к организации "Альфа". Если обмен "подцепил" не ту карточку контрагента, он никогда не найдет на ней договор, привязанный к другой карточке, даже если GUID совпадает.
Если вы исправили сопоставление вручную, но при следующем обмене все возвращается назад, попробуйте радикальный метод:
ПубличныеИдентификаторыСинхронизируемыхОбъектов.Обратите внимание на версию формата EnterpriseData (например, 1.13, 1.15). В новых версиях 1С часто обновляет состав полей поиска. Проверьте в настройках синхронизации, чтобы в обеих базах использовалась максимально близкая версия формата. Это минимизирует расхождения в логике работы общих модулей менеджера обмена.
Подводя итог, отметим, что ключ к решению проблем с договорами в универсальном формате лежит в цепочке "Организация -> Контрагент -> Договор". Только при корректном сопоставлении всех звеньев этой цепи регистрация публичных идентификаторов будет работать стабильно. Для контроля результатов обмена есть автоматическая сверка данных и выявление расхождений между УТ 11.5 и БП 3.0.