Почему возникает ошибка при загрузке правил обмена КД 2 в план обмена БСП и как её решить?

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

Однако именно на этапе загрузки правил в План обмена БСП часто возникает критическая ошибка. Программа прерывает загрузку и выдает в журнал регистрации сообщения следующего вида:

• Реквизит "Активность" не существует в табличной части (стандартной табличной части, движениях) "Удержания" объекта "Начисление зарплаты и взносов".
• Реквизит "ВалютаДт" не существует в табличной части (стандартной табличной части, движениях) "Хозрасчетный" объекта "Списание безналичных денежных средств".

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

Выясняем причину конфликта: почему «Универсальный обмен» работает, а БСП — нет?

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

Внешняя обработка «Универсальный обмен данными XML» ориентирована на непосредственное выполнение обмена. Она не производит жесткой предварительной валидации структуры правил на стопроцентное соответствие физическим метаданным. Если в правилах описано свойство, которого нет в объекте, обработка может просто проигнорировать его при выгрузке или выдать предупреждение в процессе работы, но сам процесс импорта правил в нее проходит без проблем.

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

Рассмотрим подробнее две самые частые ошибки валидации:

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

Теперь, когда причины понятны, рассмотрим по шагам, как решить эту проблему.

---

Решение 1. Отказ от переноса движений и проведение документов в базе-приемнике (Рекомендуемый путь)

В методологии разработки 1С перенос документов вместе с их движениями (записями регистров) считается архитектурным антипаттерном. Правильный и самый надежный подход — переносить только сами документы (их реквизиты и табличные части), а в базе-приемнике запускать их проведение. Это гарантирует актуальность движений и исключает возникновение коллизий в регистрах.

Для реализации этого подхода выполним следующие действия в конфигурации «Конвертация данных 2.1»:

1. Откроем наши правила обмена в КД2.
2. Перейдем в дерево правил и найдем группы свойств, отвечающие за движения документов (обычно они сгруппированы в ПКО документов под именами соответствующих регистров накопления, расчета или бухгалтерии).
3. Полностью удалим или отключим правила конвертации групп свойств (ПКГС) для всех регистров (в частности, для регистра Хозрасчетный у документа СписаниеБезналичныхДенежныхСредств и регистра Удержания у документа НачислениеЗарплатыИВзносов).
4. Сохраним правила обмена и заново загрузим их в План обмена БСП.

Для того чтобы документы автоматически проводились в базе-приемнике после загрузки, мы можем использовать стандартный механизм БСП или прописать обработчик в КД2. Например, в ПКО нужного документа на вкладке «После загрузки» можно написать следующий код:

// Режим записи документа при загрузке
РежимЗаписи = РежимЗаписиДокумента.Проведение;

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

---

Решение 2. Отключение конфликтующих ПКС в Конвертации данных 2

Если в вашей бизнес-логике перенос движений документов является критически важным (например, переносятся ручные операции, корректировки записей регистров или документы, которые нельзя проводить в приемнике «задним числом»), нам придется оставить выгрузку движений, но точечно отключить проблемные свойства.

Разберем этот процесс по шагам:

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

Если значения этих полей критически важны для переноса, мы можем заполнить их на стороне приемника в обработчике ПослеЗагрузки, обратившись к метаданным напрямую, либо передать их через параметры (исходящие данные) и обработать программно, минуя стандартное сопоставление ПКС.

---

Решение 3. Правильная выгрузка структуры метаданных конфигурации

Часто корни проблемы лежат в самом начале работы — на этапе выгрузки метаданных из конфигурации-источника. Если вы используете стандартную обработку MD83Exp.epf (Выгрузка описания конфигурации), по умолчанию она выгружает абсолютно все объекты со всеми связями.

Для такой огромной конфигурации, как 1С:Комплексная автоматизация 2, автоматическая генерация правил «для всего подряд» создает колоссальный объем избыточных и некорректных связей. Проанализируем, как сделать «чистую» выгрузку:

1. Запустим обработку MD83Exp.epf в нашей информационной базе.
2. В окне настройки выгрузки снимем флажки с разделов «Регистры накопления», «Регистры расчета» и «Регистры бухгалтерии», если перенос движений документов не требуется.
3. Выгрузим файл структуры метаданных (.xml).
4. В КД2 создадим новые правила обмена на основе этой «чистой» структуры. Не нажимайте кнопку «Создать все возможные правила» для всей конфигурации целиком! Создавайте ПКО вручную только для тех справочников и документов, которые реально участвуют в обмене по вашей организации.

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

---

Решение 4. Обход валидации БСП программным путем (Вариант «костыля»)

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

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

// Примерный фрагмент кода БСП, вызывающий ошибку:
Если Не МетаданныеОбъектаСодержитРеквизит Тогда
    ВызватьИсключение НСтр("ru = 'Реквизит не существует в табличной части...'");
КонецЕсли;

4. Мы можем временно закомментировать этот блок генерации исключения или обернуть его в попытку-исключение. Это позволит БСП «закрыть глаза» на несоответствия и успешно завершить загрузку правил обмена в План обмена.

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

---

Решение 5. Использование внешней обработки совместно с Планом обмена

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

1. Создаем План обмена в конфигурации. Он будет выполнять только одну задачу — регистрировать изменения объектов (справочников и документов) по нужной организации. Правила обмена в сам План обмена мы загружать не будем!
2. Для выполнения выгрузки используем стандартную обработку УниверсальныйОбменДаннымиXML.
3. Настроим регламентное задание, которое будет запускать эту обработку по расписанию. При запуске обработки мы будем передавать ей наши правила обмена (в виде внешнего файла) и указывать в качестве источника выборки зарегистрированные изменения из нашего Плана обмена.

Пример программного запуска выгрузки по плану обмена с использованием обработки УниверсальныйОбменДаннымиXML:

ОбработкаОбмена = Обработки.УниверсальныйОбменДаннымиXML.Создать();
ОбработкаОбмена.ИмяФайлаПравилОбмена = "C:\Rules\ExchangeRules.xml";
ОбработкаОбмена.ИмяФайлаДанных = "C:\Exchange\DataOut.xml";
ОбработкаОбмена.РежимОбмена = "Выгрузка";

// Настраиваем отбор по плану обмена
ОбработкаОбмена.ИспользоватьОтборПоПлануОбмена = Истина;
ОбработкаОбмена.ПланОбменаДляОтбора = ПланыОбмена.МойНовыйПланОбмена.НайтиПоКоду("001");

ОбработкаОбмена.ВыполнитьВыгрузку();

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

Резюме

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