Почему при синхронизации в 1С справочники переносятся частично (только поля поиска) и как это исправить

← На главную

Разработчики, часто работающие с механизмом «Конвертации данных 2.1», нередко сталкиваются со следующей крайне неприятной ситуацией. Написанные правила обмена проходят успешное тестирование в ручном режиме: при использовании стандартной обработки УниверсальныйОбменДаннымиXML все документы и связанные справочники (например, Номенклатура, Контрагенты, Склады) переносятся полностью, со всеми реквизитами и табличными частями. Однако, стоит только внедрить эти же самые правила в типовую синхронизацию данных на базе Библиотеки стандартных подсистем (БСП) — например, настроить регулярный обмен между конфигурациями Управление торговлей 10.3 и Бухгалтерия предприятия 3.0, — как обмен начинает вести себя некорректно.

В базу-приемник переносятся только те реквизиты справочников, которые отмечены в правилах как «поля поиска» (чаще всего это только Код или Наименование). Все остальные свойства (например, ставки НДС, группы, производители) остаются незаполненными. Более того, полностью игнорируются обработчики событий загрузки, такие как ПриЗагрузке и ПослеЗагрузки, а также теряются переданные параметры объектов. Давайте подробно разберем, почему так происходит, проанализируем внутреннее поведение механизмов платформы 1С и БСП и рассмотрим несколько эффективных способов решения этой проблемы.

В чем причина разного поведения механизмов обмена?

Чтобы понять суть проблемы, нам необходимо сопоставить логику работы ручной выгрузки через обработку УниверсальныйОбменДаннымиXML и автоматической онлайн-синхронизации БСП.

При использовании Универсального обмена: когда система выгружает документ (например, ПоступлениеТоваровУслуг), она последовательно обходит все его реквизиты. Натыкаясь на ссылку справочника Номенклатура, система обращается к соответствующему Правилу конвертации объектов (ПКО) для этого справочника. По умолчанию этот справочник выгружается полностью как самостоятельный <Объект> со всеми реквизитами, которые сопоставлены в Правилах конвертации свойств (ПКС). В файл выгрузки XML записывается вся структура элемента.

При использовании Синхронизации данных (БСП): здесь вступает в силу жесткая оптимизация трафика и производительности. Главный постулат БСП — передавать в транзакции только то, что действительно изменилось с момента последнего обмена. Для отслеживания изменений используется механизм планов обмена. Если изменен и зарегистрирован к выгрузке только сам документ, но связанные с ним элементы справочников (номенклатура, контрагенты) не изменялись и не были зарегистрированы на узле плана обмена, БСП принимает решение сэкономить трафик.

Вместо полноценного блока <Объект> для справочника в файл выгрузки помещается усеченный узел <Ссылка>. Этот узел содержит исключительно уникальный идентификатор (GUID) объекта и его ключевые поля поиска (например, код или артикул), необходимые для сопоставления в базе-приемнике. Предполагается, что раз элемент справочника не менялся, значит, он уже существует в приемнике, и передавать его повторно полностью нет никакого смысла.

К каким последствиям приводит выгрузка «только по ссылке»?

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

Игнорирование обработчиков событий: обработчики ПриЗагрузке, ПослеЗагрузки и другие аналогичные события на стороне базы-приемника выполняются платформой 1С только при парсинге полноценного XML-блока <Объект>. Для блоков формата <Ссылка> эти обработчики попросту не вызываются.
Потеря параметров объекта: если вы передавали дополнительные данные (например, флаги проведения или служебные реквизиты) через коллекцию ПараметрыОбъекта, они не попадут в базу-приемник. Блок <Ссылка> физически не предусматривает хранение и передачу параметров.
Появление пустых или «битых» элементов: если по какой-то причине переносимого справочника еще нет в базе-приемнике (например, при первоначальном заполнении или сбоях), а в правилах ПКО для него не установлена опция «Не создавать новый объект, если он не найден», система создаст новый элемент. Но так как в файле обмена были только поля поиска, в приемнике появится пустая карточка, у которой будет заполнен, к примеру, только Код, а все остальные важные поля останутся пустыми.

Способ 1: Принудительная выгрузка объекта через код (ВыгрузитьОбъект = Истина)

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

Рассмотрим по шагам, как это реализовать в «Конвертации данных 2.1»:

Откройте ваши правила обмена в конфигурации «Конвертация данных».
Найдите нужное ПКО документа (например, ПоступлениеТоваровУслуг) и перейдите на вкладку Конвертация свойств.
Найдите ПКС нужного ссылочного реквизита (например, Контрагент или Номенклатура) и откройте его свойства.
Перейдите к обработчику событий ПередВыгрузкой.
Пропишите в поле обработчика следующее выражение:


// Принудительно выгружаем объект полностью со всеми реквизитами и табличными частями
ВыгрузитьОбъект = Истина;

Как это работает: инициализация переменной ВыгрузитьОбъект значением Истина является для выгрузчика директивой обязательного формирования полноценного XML-узла <Объект>. В этом случае БСП проигнорирует отсутствие регистрации элемента справочника в плане обмена и запишет его структуру целиком. Это гарантирует вызов обработчиков ПослеЗагрузки на стороне приемника.

Минусы подхода: данный метод увеличивает размер файла обмена. Если в документе содержится табличная часть на 10 000 строк с уникальной номенклатурой, использование этого флага заставит систему выгружать все 10 000 карточек номенклатуры при каждой выгрузке документа, даже если они давно созданы в приемнике. Используйте этот способ точечно, только для критически важных реквизитов (например, реквизитов шапки документа — Договор, Контрагент, Склад).

Способ 2: Настройка автоматической регистрации связанных объектов (Архитектурно верный путь)

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

Если справочник зарегистрирован к обмену, БСП увидит это и выгрузит его как полноценный <Объект> без использования принудительных флагов в ПКС. Добиться этого можно двумя путями:

А. Использование подписок на события в конфигурации-источнике

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


Процедура ЗарегистрироватьСвязанныеСправочникиПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
    
    // Получаем узел обмена, для которого нужно зарегистрировать изменения
    // В реальной задаче здесь должен быть обход активных узлов нужного плана обмена
    УзлыДляРегистрации = ПланыОбмена.ОбменУправлениеТорговлейБухгалтерияПредприятия.Выбрать();
    
    Пока УзлыДляРегистрации.Следующий() Цикл
        
        // Регистрируем реквизиты шапки документа
        Если ЗначениеЗаполнено(Источник.Контрагент) Тогда
            ПланыОбмена.ЗарегистрироватьИзменения(УзлыДляРегистрации.Ссылка, Источник.Контрагент);
        КонецЕсли;
        
        Если ЗначениеЗаполнено(Источник.Склад) Тогда
            ПланыОбмена.ЗарегистрироватьИзменения(УзлыДляРегистрации.Ссылка, Источник.Склад);
        КонецЕсли;
        
        // Регистрируем номенклатуру из табличной части Товары
        Для Каждого СтрокаТовары Из Источник.Товары Цикл
            Если ЗначениеЗаполнено(СтрокаТовары.Номенклатура) Тогда
                ПланыОбмена.ЗарегистрироватьИзменения(УзлыДляРегистрации.Ссылка, СтрокаТовары.Номенклатура);
            КонецЕсли;
        КонецЦикла;
        
    КонецЦикла;
    
КонецПроцедуры

Б. Использование Правил регистрации объектов (ПРО)

Если вы не хотите вносить изменения в конфигурацию-источник и создавать новые подписки, настройте логику регистрации в самой «Конвертации данных 2.1» с помощью Правил регистрации объектов (ПРО). В ПРО можно гибко прописать скрипты, которые при регистрации документа будут автоматически ставить в очередь на выгрузку все связанные с ним справочники. Это сохранит конфигурацию типовой и решит проблему неполной выгрузки.

Способ 3: Настройка параметров ПКО в Конвертации данных

Если вам действительно не нужно переносить все реквизиты справочника заново (например, карточки справочников в приемнике гарантированно заполнены корректно), но вы хотите застраховать систему от создания пустых «битых» элементов при случайном отсутствии объекта в приемнике, настройте поведение ПКО:

Откройте Правило конвертации объектов (ПКО) для проблемного справочника (например, Номенклатура).
Установите флаг «Не создавать новый объект, если он не найден». В этом случае, если объект не будет найден в приемнике по полям поиска, система не станет плодить пустые карточки с одним лишь кодом, а оставит реквизит в документе пустым, либо выдаст предупреждение в лог (в зависимости от настроек).
Изучите настройку флага «При переносе объекта по ссылке НЕ создавать новый объект, а только переносить ссылку». Эта опция позволяет жестко разграничить логику создания новых элементов в базе-приемнике.

Резюме

Проанализировав проблему, мы видим, что «срезание» реквизитов справочников при синхронизации — это не баг платформы 1С, а заложенное поведение оптимизации БСП. Для быстрого исправления «здесь и сейчас» используйте установку флага ВыгрузитьОбъект = Истина; в ПКС правил обмена. Для создания надежной, промышленной интеграции без раздувания xml-файлов всегда отдавайте предпочтение правильной настройке планов обмена и авторегистрации связанных данных.