При настройке обмена данными между современными конфигурациями 1С, использующими Библиотеку стандартных подсистем (БСП), разработчики часто сталкиваются с необходимостью использования собственных правил, созданных в конфигурации Конвертация данных 2.1. Одной из первых сложностей становится формат передачи этих правил: система требует не одиночный XML-файл, а специализированный ZIP-архив. Разберем подробно, как подготовить этот архив, как правильно назвать файлы внутри него и как избежать типичных ошибок при настройке регистрации объектов.
Рассмотрим стандартные требования платформы к загружаемому файлу. Для корректной работы механизма синхронизации в типовых решениях (таких как БП 3.0, ERP 2.5, ЗУП 3.1) необходимо подготовить ZIP-архив, содержащий строго определенные файлы. Проанализируем назначение каждого из них:
Важный нюанс: имена файлов в архиве должны быть написаны в точности так, как указано выше. Регистр символов имеет значение. Если вы назовете файл Rules.xml или exchange_rules.xml, система выдаст ошибку о невозможности прочитать правила.
Часто для создания собственных правил эффективнее всего взять за основу типовые. Выясним, как их получить из работающей базы. В интерфейсе настройки синхронизации данных (раздел «Администрирование» — «Синхронизация данных» — «Настройки синхронизации») выберите нужный узел обмена. В командной панели или в меню «Еще» найдите пункт «Сохранить правила конвертации в файл». Система предложит сохранить ZIP-архив. Распаковав его, мы увидим эталонную структуру файлов, которую и следует использовать при подготовке своих доработок.
Если в пользовательском интерфейсе нужная кнопка отсутствует, проанализируем ситуацию через Конфигуратор. Большинство типовых правил хранятся в объекте ПланОбмена в ветке Макеты. Найдите макеты с именами ПравилаОбмена или ПравилаРегистрации, откройте их и сохраните как текстовые файлы с расширением .xml.
Разберем распространенную проблему: при попытке создать RegistrationRules.xml в Конвертации данных 2.1 список объектов пуст, и выбрать документы или справочники невозможно. Выясним причину этого поведения.
Правила регистрации неразрывно связаны с метаданными конкретного плана обмена. Чтобы объекты появились в КД 2.1 при настройке регистрации, необходимо выполнить следующие шаги:
ПланОбмена.RegistrationRules.xml прописаны условия его регистрации. Это наиболее гибкий и профессиональный подход.После изменения состава плана обмена необходимо заново выгрузить структуру метаданных с помощью обработки MD83Exp.epf и загрузить ее в «Конвертацию данных». Только после этого в интерфейсе создания правил регистрации появятся нужные объекты.
Когда архив сформирован и включает в себя все три XML-файла, переходим к этапу загрузки. В современных конфигурациях это делается через форму настройки синхронизации. Посмотрим на алгоритм действий:
Если система выдает ошибку, проанализируем Журнал регистрации. БСП при загрузке правил делает подробные записи о том, какой именно файл в архиве не прошел валидацию. Часто ошибка кроется в несоответствии пространства имен или версии платформы, указанной в заголовке XML-файла.
Для одностороннего обмена (например, из БП в ERP), где не планируется обратная загрузка, правила CorrespondentExchangeRules.xml могут быть минимальными. Пример структуры пустого файла правил конвертации, который можно использовать для заглушки:
<?xml version="1.0" encoding="UTF-8"?>
<ПравилаОбмена>
<ВерсияФормата>2.01</ВерсияФормата>
<Ид>00000000-0000-0000-0000-000000000000</Ид>
<Наименование>Пустые правила</Наименование>
<ДатаВыгрузки>2023-10-27T10:00:00</ДатаВыгрузки>
<Источник>ERP</Источник>
<Приемник>БухгалтерияПредприятия</Приемник>
<ПравилаКонвертацииОбъектов/>
<ПравилаВыгрузкиДанных/>
</ПравилаОбмена>
Важно помнить, что современные конфигурации на платформе 8.3 все чаще используют КД 3.0 (формат EnterpriseData). Однако поддержка правил КД 2.1 сохраняется как «Универсальный обмен данными через план обмена». Если вы используете именно этот механизм, убедитесь, что в вашей ERP включена соответствующая функциональная опция в настройках синхронизации. Проанализируем также, что правила регистрации (RegistrationRules) в обеих технологиях (КД 2.1 и КД 3.0) концептуально схожи: они всегда работают на стороне источника и опираются на состав плана обмена, определенный в Конфигураторе.
Используя данный системный подход, мы обеспечим стабильную работу обмена и сможем гибко управлять регистрацией и конвертацией данных в любых распределенных системах на базе 1С.