Как настроить обмен номенклатурой с сохранением иерархии групп между базами 1С:Управление торговлей 11

← На главную

При настройке типового синхронного обмена между двумя идентичными конфигурациями «1С:Управление торговлей 11» через универсальный формат EnterpriseData разработчики часто сталкиваются с ситуацией, когда товары переносятся без сохранения структуры папок. В базе-приемнике элементы попадают в корень справочника Номенклатура, а иерархическая привязка к группам сбрасывается. Рассмотрим, почему возникает эта проблема и какими способами можно организовать правильную передачу данных по расписанию.

Причины потери иерархии при синхронизации

Проанализируем работу механизмов платформы при регистрации и выгрузке объектов:

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

Способ 1. Доработка правил регистрации объектов (ПРО) в «Конвертации данных 2.0»

Типовой и наиболее корректный подход — внесение изменений в правила регистрации объектов (ПРО). В архитектуре обменов 1С на основе EnterpriseData сами правила обмена (ПКО) редактируются в «Конвертации данных 3.0», а правила регистрации для них — в «Конвертации данных 2.0».

Разберем порядок действий:

Выгрузим типовые правила регистрации из конфигурации «Управление торговлей 11».
Откроем правила в конфигурации «Конвертация данных 2.0».
Для объекта справочника Номенклатура настроим каскадную регистрацию родителей: при регистрации элемента алгоритм должен автоматически помещать в таблицу изменений всю цепочку вышестоящих папок (Родитель).
Добавим необходимый отбор по конкретной группе прямо в правила регистрации. Это предотвратит попадание лишних данных в таблицу изменений и избавит от необходимости фильтровать данные при отправке.
Загрузим обновленные правила в настройки обмена (или через подключение в узле плана обмена).

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

Способ 2. Программирование обработчиков в модуле плана обмена

Если требуется быстро ограничить выгрузку или скорректировать логику передачи объектов без использования конфигуратора КД, можно переопределить события в модуле соответствующего плана обмена.

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


Процедура ПриОтправкеДанныхПодчиненному(ЭлементДанных, ОтправкаЭлемента, СозданиеНачальногоОбраза)
    
    Если ТипЗнч(ЭлементДанных) = Тип("СправочникОбъект.Номенклатура") Тогда
        // Проверяем условия (например, принадлежность к группе)
        Если Не ЭлементДанных.ПринадлежитЭлементу(НужнаяГруппа) Тогда
            ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
        КонецЕсли;
    КонецЕсли;

КонецПроцедуры

Аналогично на стороне приемника можно переопределить обработчик ПриПолученииДанныхОтГлавного для фильтрации входящих данных:


Процедура ПриПолученииДанныхОтГлавного(ЭлементДанных, ПолучениеЭлемента, ОтправкаНазад)

    Если ТипЗнч(ЭлементДанных) = Тип("СправочникОбъект.БанковскиеСчета")
        И ТипЗнч(ЭлементДанных.Владелец) = Тип("СправочникСсылка.Организации")
        И Не (ЭлементДанных.Владелец = УпрОрг Или ЭлементДанных.Владелец = РеглОрг) Тогда
        
        ПолучениеЭлемента = ПолучениеЭлементаДанных.Игнорировать;
    КонецЕсли;

КонецПроцедуры

Важно учитывать: Использование значения ОтправкаЭлементаДанных.Игнорировать предотвращает запись объекта в файл обмена, но объект может оставаться в таблице регистрации изменений, если логика снятия с регистрации не настроена дополнительно. Кроме того, такие доработки рекомендуется выносить в расширение конфигурации.

Способ 3. Использование HTTP-сервисов или REST API (OData)

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

Встроенный интерфейс OData: Платформа позволяет включить доступ по OData для справочника Номенклатура. В базе-приемнике регламентным заданием отправляется запрос к OData источника, откуда считывается полная структура справочника вместе с реквизитами Родитель и восстанавливается иерархия.
Собственный HTTP-сервис в расширении: Создается расширение с HTTP-сервисом, который по запросу отдаёт JSON со структурой групп и элементов. На стороне приемника регламентное задание по расписанию запрашивает изменения и рекурсивно создает сначала группы, а затем подчиненные элементы.

Резюме и рекомендации

Проанализировав возможные варианты решения задачи, выделим основные рекомендации:

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