Откуда 1С берет правила обмена при синхронизации УТ 10.3 и БП 3.0 и как их обновить?

Программист 1С v8.3 (Обычные формы) 1С:Управление торговлей IT и автоматизация бизнеса
← На главную

При сопровождении обменов между Управление торговлей 10.3 и Бухгалтерия предприятия 3.0 программисты часто сталкиваются с ситуацией, когда внесенные изменения в правила конвертации через конфигуратор (в макеты плана обмена) никак не отражаются на процессе выгрузки или загрузки данных. Мы можем удалять реквизиты, менять логику сопоставления или вовсе очищать правила, но система продолжает работать по старому алгоритму. В этой статье мы подробно разберем, где именно 1С хранит правила обмена, какой источник является приоритетным и как правильно обновить логику синхронизации, чтобы изменения вступили в силу.

Разбор архитектуры хранения правил обмена

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

  1. Регистр сведений «Правила для обмена данными». Это самый важный и приоритетный источник. Если в данный регистр загружены правила в виде двоичных данных для конкретного узла или вида обмена, система будет использовать их, полностью игнорируя то, что написано в конфигураторе. Это сделано для возможности оперативной правки обмена "на лету" без снятия базы с поддержки и обновления конфигурации.
  2. Внешний файл на диске. В настройках синхронизации в режиме «1С:Предприятие» можно явно указать использование внешних правил, выбрав файл формата .xml.
  3. Общие макеты в Конфигураторе. Если в регистре сведений пусто и внешний файл не выбран, система обращается к макетам конфигурации, которые обычно называются ПравилаОбмена_... или ПравилаРегистрации_....

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

Шаг 1: Поиск и актуализация правил в режиме Предприятие

Выясним, как найти нужные настройки. В конфигурации Бухгалтерия предприятия 3.0 (приемник) или Управление торговлей 10.3 (источник, если обмен инициируется оттуда) необходимо перейти в раздел настроек синхронизации данных.

Проанализируем последовательность действий для актуализации правил:

  1. Откроем список настроек синхронизации данных.
  2. Выберем нужную настройку обмена с БП 3.0.
  3. Найдем пункт «Загрузить правила обмена данными» или «Параметры обмена данными».
  4. В открывшейся форме мы увидим переключатель: «Использовать правила из конфигурации» или «Использовать правила из внешнего файла».

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

Шаг 2: Работа с регистром «Правила для обмена данными»

Если через стандартный интерфейс настроек найти источник не удается, воспользуемся «тяжелой артиллерией» — прямым обращением к регистру. Проделаем следующие шаги:

  1. Перейдем в «Все функции» (или «Функции для технического специалиста»).
  2. Найдем регистр сведений ПравилаДляОбменаДанными.
  3. Проанализируем записи в нем. Нас интересуют записи, где в колонке ИмяПланаОбмена указан наш обмен.
  4. В этом регистре правила хранятся в ресурсе с типом ХранилищеЗначения.

Если вы обнаружили там запись для вашего обмена, значит, система берет данные именно отсюда. Чтобы принудительно заставить 1С использовать макеты из конфигурации, эту запись можно временно удалить (предварительно сделав бэкап или выгрузив правила в файл) либо обновить содержимое ресурса актуальным файлом .xml, подготовленным в Конвертации данных 2.1.

Шаг 3: Модификация правил для документа «Требование-накладная»

Рассмотрим специфическую задачу автора: убрать реквизит НоменклатурнаяГруппа из табличной части. С обновлением БП 3.0 структура этого документа изменилась (в связи с новыми стандартами ФСБУ 5/2019), и реквизит может отсутствовать в метаданных или быть переименован.

Разберем алгоритм работы в программе «Конвертация данных 2.1»:

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

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


// Пример: удаление старой аналитики в обработчике
// Если Объект.Метаданные().ТабличныеЧасти.Материалы.Реквизиты.Найти("НоменклатурнаяГруппа") <> Неопределено Тогда
//     СтрокаТЧ.НоменклатурнаяГруппа = ... 
// КонецЕсли;

Проблема кэширования правил

Даже после того, как мы обновили правила в регистре или конфигурации, 1С может продолжать использовать старые алгоритмы из-за кэширования. Выясним, как с этим бороться:

  1. Очистка временных файлов. 1С кэширует скомпилированные модули правил в папке пользователя AppData\Local\1C\1Cv8\.... При радикальных изменениях правил рекомендуется полностью очистить локальный кэш.
  2. Перерегистрация объектов. Если объекты уже были зарегистрированы к обмену (в таблицах регистрации изменений плана обмена), они могут содержать в себе данные, подготовленные по старой схеме. Попробуем отменить регистрацию для документа Требование-накладная и зарегистрировать его заново после обновления правил.

Итоги и рекомендации

Подводя итог нашему исследованию, можно составить четкий чек-лист для проверки источника правил:

Помните, что в сильно переписанных конфигурациях (как в случае с УТ 10.3 у автора) разработчики могли внедрить свои механизмы хранения правил, например, в справочниках или дополнительных константах. В таком случае поможет только глобальный поиск по конфигурации или использование отладчика в модуле обмена для отслеживания момента загрузки структуры правил.

← На главную