Почему при создании правил регистрации объектов в Конвертации данных не видны регистры и как это исправить

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

Различие в инструментах выгрузки метаданных для КД 2.1 и КД 3.0

Первая и самая распространенная причина, по которой объекты могут «пропасть» — использование неподходящей обработки для выгрузки структуры конфигурации. Рассмотрим подробнее, почему это происходит. Существует два принципиально разных подхода к интеграции:

1. Конвертация данных 2.1: работает с форматом XML и требует полной структуры метаданных. Для выгрузки описания конфигурации используется обработка MD83exp.epf (для платформы 8.3).
2. Конвертация данных 3.0: базируется на технологии EnterpriseData и формате XDTO. Обработка выгрузки для этой версии формирует структуру, ориентированную на схемы XDTO.

Проанализируем ситуацию: если вы по ошибке воспользуетесь обработкой из поставки КД 3.0 для создания правил в КД 2.1, вы получите файл, в котором могут отсутствовать регистры. Это связано с тем, что в технологии XDTO-обмена регистры практически не используются как самостоятельные единицы обмена — данные передаются через документы. Поэтому, приступая к работе, обязательно убедитесь, что вы используете обработку именно для версии 2.1.

Проверка состава плана обмена в конфигурации

Даже если структура метаданных выгружена правильно, объект может не появиться в списке для создания Правил регистрации объектов (ПРО). Выясним причину этого поведения платформы. Механизм регистрации изменений в 1С жестко завязан на объект метаданных ПланОбмена.

Рассмотрим пошагово, что необходимо проверить в конфигураторе:

1. Откроем дерево метаданных и найдем План обмена, для которого создаются правила.
2. Перейдем на вкладку «Состав».
3. Проверим, включен ли нужный нам регистр (например, Хозрасчетный или любой РегистрНакопления) в этот список.

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

Настройка параметров обработки MD83exp.epf

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

• Выгружать движения регистров: если эта галочка не установлена, информация о регистрах накопления и бухгалтерии не попадет в файл xml.
• Выгружать только объекты, включенные в планы обмена: это критически важная настройка. Если она включена, а ваш регистр еще не добавлен в состав плана обмена в конфигураторе, он будет проигнорирован при выгрузке.
• Выгружать регистры сведений: убедитесь, что этот пункт отмечен, особенно если вы работаете с независимыми регистрами.

Проанализируем типичный сценарий: разработчик добавил новый регистр в расширение или основную конфигурацию, забыл включить его в план обмена и запустил выгрузку с установленным фильтром по плану обмена. В итоге в КД 2.1 объект не виден. Решение — либо добавить объект в состав плана обмена, либо снять флаг фильтрации при выгрузке (хотя для ПРО первый вариант является обязательным).

Особенности работы с ERP и КД 2.1

Стоит затронуть вопрос архитектурного выбора. Использование КД 2.1 для 1С:ERP в сообществе часто считается «странным» выбором. Это связано с тем, что ERP — тяжелая система, и стандартный механизм обмена через XML (который использует КД 2.1) может работать медленнее, чем современная синхронизация через КД 3.0.

Однако, существуют ситуации, когда КД 2.1 оправдана:

• Необходимость быстрого «разового» переноса данных.
• Специфические требования к трансформации данных, которые сложно реализовать в логике XDTO.
• Обмен со старыми конфигурациями (например, УПП 1.3), где нет поддержки КД 3.0.

Если вы все же решили использовать КД 2.1, помните о подписках на события. В ERP регистрация часто управляется не «авторегистрацией», а через программный код в подписках. При создании ПРО убедитесь, что в правилах указан верный режим регистрации изменений.

Алгоритм исправления проблемы

Подведем итог и составим четкий алгоритм действий, чтобы нужный объект появился в справочнике метаданных КД 2.1:

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

После выполнения этих шагов при создании новой записи в справочнике «Правила регистрации объектов» и выборе типа объекта, ваш регистр гарантированно появится в списке. Это позволит вам гибко настроить условия, при которых данные регистра будут попадать в очередь на выгрузку, например, используя обработчики ПередОбработкой или ПриОбработке.

Пример программной проверки условия регистрации в ПРО (код пишется в обработчиках КД):

// Пример в обработчике "Перед обработкой" правила регистрации
// Проверяем организацию для регистра бухгалтерии
Если Объект.Организация <> Параметры.ОрганизацияОбмена Тогда
    Отказ = Истина;
КонецЕсли;

Соблюдение этих технических нюансов сэкономит время при настройке сложных систем интеграции и обеспечит корректную работу миграции данных в экосистеме 1С.