Как настроить автоматический обмен данными между одинаковыми конфигурациями 1С:Управление торговлей 11 без использования РИБ?

При разделении учета на несколько информационных баз (например, оптовое и розничное направления на базе одинаковой редакции 1С:Управление торговлей 11) нередко возникает необходимость автоматического обмена документами и справочниками с их взаимной трансформацией. Классический механизм распределенных информационных баз (РИБ) в таких случаях не подходит: он требует жесткой синхронизации метаданных, блокирует независимое изменение конфигураций и не позволяет трансформировать документы «на лету» (например, конвертировать документ РеализацияТоваровУслуг в ПриобретениеТоваровУслуг).

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

Анализ типовых механизмов: EnterpriseData (КД 3.0) против правил конвертации (КД 2.0)

В современных версиях типовых конфигураций на базе БСП присутствуют два базовых подхода к синхронизации:

1. Синхронизация через универсальный формат EnterpriseData (КД 3.0): Штатно в конфигурации присутствует план обмена СинхронизацияДанныхЧерезУниверсальныйФормат. Обмен настраивается интерактивно («Синхронизация данных с другой программой») и работает по регламентному заданию. Однако формат EnterpriseData в типовом виде ориентирован на сценарии интеграции разных конфигураций (УТ — БП, УТ — Розница). В нем могут отсутствовать обработчики загрузки чисто управленческих документов (например, загрузка документа ЗаказКлиента), регистров сведений или специфических реквизитов (штрихкоды, характеристики). Если требуется использовать EnterpriseData, типовые правила придется дорабатывать в конфигурации.
2. Обмен по правилам конвертации (КД 2.0): Проверенный классический механизм, обеспечивающий произвольную трансформацию любых объектов данных и регистров. Для его использования в современных конфигурациях требуется зарегистрировать собственный план обмена в подсистеме БСП либо адаптировать существующий.

Вариант 1. Использование универсального формата EnterpriseData и доработка обработчиков

Если мы выбираем архитектуру EnterpriseData, нам не требуется модифицировать состав планов обмена. Настройка выполняется через стандартное меню синхронизации. Однако при передаче специфических документов мы сталкиваемся с тем, что документ выгружается в формат XML, но в базе-приемнике нет логики его разбора.

Разберем по шагам, как устранить подобные ограничения:

1. Откроем модуль менеджера МенеджерОбменаЧерезУниверсальныйФормат в базе-приемнике.
2. Найдем обработчик получения данных соответствующего объекта (или создадим процедуру по шаблону, например для ЗаказКлиента).
3. В процедурах формата ПКО_..._ПередЗаписьюПолученныхДанных переопределим логику заполнения реквизитов и поиска объекта, если типовое сопоставление по идентификаторам не подходит.
4. Для передачи данных, отсутствующих в базовой схеме XDTO (например, записей независимых регистров сведений или дополнительных штрихкодов), упакуем их на стороне источника в структуру дополнительных свойств или реквизит ДополнительныеРеквизиты, а на стороне приемника извлечем и программно запишем в целевой регистр сведений.

Вариант 2. Создание собственного плана обмена на базе КД 2.0 в архитектуре БСП

Когда требуется глубокая кастомизация, перенос произвольных регистров и трансформация документов (например, зеркалирование реализации в поступление), оптимальным решением остается использование правил КД 2.0, встроенных в инфраструктуру БСП.

Проанализируем шаги добавления такого обмена в конфигурацию:

1. Создание или копирование плана обмена: В дереве метаданных скопируем один из планов обмена, использующих правила КД 2.0 (например, ОбменУправлениеТорговлейБухгалтерияПредприятия или специализированный план обмена с предыдущими редакциями). Присвоим новому плану обмена корректное имя и синоним. Очистим лишние реквизиты и табличные части, оставив параметры отбора (например, ДатаНачалаВыгрузкиДокументов).
2. Регистрация плана в подсистеме обмена данными БСП:

   Включим новый план обмена в определяемый тип ПланОбменаПодсистемыОбменДанными.

   В общем модуле ОбменДаннымиПереопределяемый найдем процедуру ПолучитьПланыОбмена и добавим наш план обмена в список с указанием использования правил:

   Скопировать код

   
   Процедура ПолучитьПланыОбмена(ПодсистемыОбменаДанными) Экспорт
       
       // Регистрация нового плана обмена
       ПланОбмена = ПодсистемыОбменаДанными.Добавить();
       ПланОбмена.Имя = "НашПланОбменаУТ_УТ";
       ПланОбмена.ИспользоватьПравилаКонвертации = Истина;
       ПланОбмена.ИспользоватьПравилаРегистрации = Истина;
       
   КонецПроцедуры
   

3. Подключение команд синхронизации: Добавим созданный план обмена в команды ВыполнитьОбменДанными и ВыполнитьОбменДаннымиИнтерактивно, а также при необходимости дополним процедуру ПолучитьСписокПлановОбмена в модуле ОбменДаннымиУТУП.
4. Настройка регистрации изменений: Добавим созданный план обмена в состав общих подписок на события БСП, отвечающих за фиксацию изменений (события ПередЗаписью и ПриЗаписи для справочников и документов). При необходимости точечной фильтрации зарегистрируем собственные правила регистрации данных, выгруженные из конфигурации «Конвертация данных 2.1».
5. Загрузка правил: В пользовательском режиме перейдем в форму настроек обмена, создадим новую настройку и загрузим подготовленный в КД 2.0 файл правил конвертации. Расписание выполнения задается стандартным регламентным заданием БСП.

Особенности трансформации документов (РТиУ в ПТиУ) и ссылочной целостности

Рассмотрим важную техническую деталь: при конвертации документа одного вида в другой нельзя напрямую переносить уникальный идентификатор (УникальныйИдентификатор), так как идентификаторы в платформе 1С привязаны к конкретным таблицам метаданных. Попытка записать объект другого типа с чужим UUID вызовет конфликт ссылочной целостности.

Для исключения дублирования документов при регулярном автоматическом обмене применим следующий алгоритм:

1. Создадим в обеих базах независимый непериодический регистр сведений СоответствиеОбъектовДляОбмена с измерениями УзелОбмена, ИдентификаторИсточника (тип Строка) и ресурсом ИдентификаторПриемника (тип Строка или прямая ссылка на объект).
2. В обработчике правил конвертации (или в коде загрузки универсального формата) перед созданием нового документа ПриобретениеТоваровУслуг выполним поиск по данному регистру сведений.
3. Если запись найдена — обновляем существующий документ в приемнике. Если записи нет — создаем новый документ и фиксируем связь между исходным Ссылка.УникальныйИдентификатор() реализации и идентификатором созданного поступления.
4. Обязательно отслеживаем установку свойства ОбменДанными.Загрузка = Истина при программной записи объектов в базе-приемнике. Это исключает повторную авторегистрацию изменений («эхо-эффект») и предотвращает зацикливание передачи одних и тех же пакетов по кругу.