Как исправить ошибку дублирования команд и правильно настроить новый план обмена в 1С:ERP?

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

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

Выясняем причину ошибки «Задано более одной команды с тем же именем»

Данная ошибка возникает из-за некорректной настройки общих команд БСП, отвечающих за синхронизацию данных. В составе Библиотеки стандартных подсистем уже предопределен набор общих команд, предназначенных для работы с планами обмена (например, запуск интерактивной синхронизации, просмотр состава отправляемых данных, загрузка правил регистрации объектов и т.д.).

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

Для исправления этой ситуации выполним следующие шаги:

1. Проанализируем структуру конфигурации и убедимся, что мы не создавали новые общие команды вручную. Если такие команды были созданы (например, в основной конфигурации или внутри расширения), их необходимо полностью удалить.
2. Найдем в дереве метаданных в ветке Общие -> ОбщиеКоманды стандартные команды БСП, связанные с обменом данными. К ним относятся:
   • Синхронизировать
   • СинхронизироватьСДополнительнымиПараметрами
   • СоставОтправляемыхДанных
   • ЗагрузитьПравилаРегистрацииОбъектов
   • СценарииСинхронизации
3. В свойствах каждой из этих команд найдем свойство «Тип параметра команды».
4. Откроем редактор типа и установим флажок напротив нашего нового плана обмена (например, БП_ERP). Тем самым мы расширяем действие типовой команды на наш новый объект метаданных, избегая дублирования самих команд.
5. Если разработка ведется в расширении конфигурации, крайне важно правильно заимствовать эти общие команды и контролировать их свойства, чтобы изменения типов параметров корректно применились в режиме «1С:Предприятие».

Правильная регистрация плана обмена в программном коде БСП

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

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

Процедура ПолучитьПланыОбмена(ПланыОбменаПодсистемы) Экспорт
    ПланыОбменаПодсистемы.Добавить(Метаданные.ПланыОбмена.БП_ERP);
КонецПроцедуры

Во-вторых, БСП при инициализации подсистемы обмена обращается к модулю менеджера регистрируемого плана обмена. Если в модуле менеджера вашего плана обмена БП_ERP отсутствует специальная экспортная процедура настройки, система выдаст ошибку во время выполнения. Откроем модуль менеджера плана обмена и добавим туда обязательный шаблон:

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

В-третьих, обратим внимание на состав нашего плана обмена. Для корректной работы механизмов сопоставления объектов БСП требует соблюдения следующих правил:

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

Настройка правил при одностороннем обмене по технологии КД 2.1

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

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

• В базе-источнике (БП 3.0): Необходимы полноценные правила конвертации объектов (файл ExchangeRules.xml), настроенные в программе «Конвертация данных 2.1», а также правила регистрации изменений (файл RegistrationRules.xml), которые определяют условия, при которых документы и справочники должны регистрироваться на узле плана обмена для отправки.
• В базе-приемнике (ERP): База-приемник должна «понимать», структуру какого XML-пакета она принимает, и как сопоставлять входящие типы данных. Для этого в макеты плана обмена в ERP (или непосредственно через режим «1С:Предприятие») загружаются следующие файлы:
  • В макет ПравилаОбмена — правила для самой ERP. Поскольку обмен односторонний и ERP ничего отправлять назад не будет, эти правила могут представлять собой «пустышку» (содержать только описание структуры метаданных ERP без реальных правил конвертации объектов PKO).
  • В макет ПравилаОбменаКорреспондента — загружаются те самые правила конвертации (ExchangeRules.xml), по которым выгружает данные БП 3.0. Это необходимо, чтобы ERP знала логику десериализации входящего файла.
  • В макет ПравилаРегистрации — можно оставить макет пустым или загрузить базовую структуру правил регистрации, так как регистрация объектов на узле ERP производиться не будет.

Практический совет: Чтобы избежать постоянного изменения конфигурации и облегчить процесс последующих обновлений «1С», не зашивайте файлы правил XML непосредственно в макеты конфигуратора. Современная БСП позволяет загружать правила конвертации и регистрации динамически в режиме «1С:Предприятие» прямо через форму узла синхронизации данных (кнопка «Загрузить правила»).

Переход на современный стандарт: Универсальный формат (EnterpriseData)

Разработка собственного плана обмена на Конвертации данных 2.1 (КД 2.1) для обмена между типовыми конфигурациями (такими как ERP и БП) — это устаревший подход, несущий в себе серьезные долгосрочные риски для стабильности бизнес-процессов.

Проанализируем основные недостатки использования КД 2.1 в современных реалиях:

1. Сложность поддержки при обновлениях: Фирма «1С» регулярно обновляет метаданные ERP и БП. При переименовании любого реквизита, изменении типов данных или структуры документов ваши самописные правила КД 2.1 мгновенно сломаются. Вам придется заново выгружать структуры метаданных обеих конфигураций, переносить их в Конвертацию данных 2.1, вручную перенастраивать правила обмена и заново загружать их в базы данных.
2. Зависимость от COM-соединений: Традиционные обмены на КД 2.1 часто используют COM-соединение для подключения к базе-корреспонденту. Технология COM нестабильно работает на современных 64-битных серверах «1С:Предприятие» и абсолютно несовместима с серверами под управлением операционных систем семейства Linux.

Для решения задачи переноса небольшого количества объектов (например, 5 видов документов и связанных справочников) гораздо эффективнее использовать встроенный Универсальный формат (EnterpriseData) и Конвертацию данных 3.0.

Выясним, в чем преимущества данного подхода и как его реализовать:

• В ERP и БП 3.0 уже встроен готовый и отлично отлаженный план обмена СинхронизацияДанныхЧерезУниверсальныйФормат. Он поддерживает обмен через файлы, FTP, электронную почту или веб-сервисы, не требуя COM-соединений.
• Вам не нужно создавать новый план обмена с нуля и сталкиваться с ошибками регистрации команд БСП. Достаточно использовать существующий канал обмена.
• Если типовые правила EnterpriseData не поддерживают перенос ваших специфических реквизитов или документов, логика обмена кастомизируется без изменения конфигурации. Для этого создается небольшое расширение конфигурации, в котором переопределяются алгоритмы обработки данных.
• В КД 3.0 вся настройка сводится к сопоставлению объектов конфигурации с объектами стандартного XDTO-пакета формата EnterpriseData. Вы кастомизируете выгрузку на стороне источника в модуле менеджера обмена через переопределение процедур ПриОтправкеДанных, а прием — на стороне ERP через процедуру ПриПолученииДанных.

Использование Универсального формата гарантирует, что ваши конфигурации останутся на полной поддержке поставщика, а плановые обновления конфигураций «1С» не приведут к остановке регулярного обмена данными между базами.