← На главную

При настройке регулярной синхронизации между конфигурациями «Управление торговлей», редакция 10.3 и «Бухгалтерия предприятия», редакция 3.0 специалисты часто сталкиваются с ситуацией, когда релиз установленной конфигурации не совпадает с релизом, указанным в типовых правилах конвертации. В результате обмен завершается аварийно, а процедура выгрузки длится часами без понятного описания ошибки. Разберем по шагам причины такого поведения и выясним, как быстро локализовать сбой и адаптировать правила обмена.

Причины сбоев при синхронизации и несоответствия версий

Проанализируем природу проблемы. Несоответствие версий и аварийное завершение обмена возникают по нескольким основным причинам:

1. Информационный номер релиза в правилах. Номер релиза, который отображается в метаданных правил в конфигурации Конвертация данных 2.1, носит преимущественно описательный характер. Фирма «1С» нередко собирает правила на предрелизных или внутренних сборках (например, 3.0.44.186), которые не выходят в открытый доступ, тогда как пользователи получают релиз 3.0.44.188. Однако в обработчиках правил (Перед выгрузкой данных или Перед загрузкой данных) может присутствовать жесткая проверка версии конфигурации через обращение к Метаданные.Версия, которая намеренно прерывает выполнение при несовпадении.
2. Изменение состава реквизитов конфигурации-приемника. Даже в минорных обновлениях «Бухгалтерии предприятия» разработчики могут переименовать или удалить устаревший реквизит (например, связанный со специфическими классификаторами алкогольной продукции или кодами ТН ВЭД). Если правило конвертации свойств (ПКС) пытается напрямую прочитать отсутствующий реквизит в приемнике, платформа выдает фатальную ошибку.
3. Массовая первичная регистрация объектов. При создании новой настройки обмена стандартный план обмена автоматически регистрирует абсолютно все данные информационной базы за всю историю ее ведения. Попытка выгрузить огромный массив документов и справочников в один XML-файл приводит к переполнению оперативной памяти, зависанию сеанса на несколько часов и падению при первой же ошибке в единичном объекте.

Шаг 1. Ограничение объема выгрузки и очистка регистрации

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

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

Шаг 2. Поиск актуальных правил обмена

Выясним, где взять корректные правила. В связке УТ 10.3 и БП 3.0 ведущей конфигурацией по изменениям законодательства выступает бухгалтерия. Поэтому правила выгрузки из УТ в БП необходимо брать не из старого дистрибутива торговли, а из каталога шаблона обновления текущего релиза «Бухгалтерии предприятия» (каталог вида tmplts\1c\Accounting\3_0_XX_XX\Обмены данными\Обмен с конфигурацией Управление торговлей, ред. 10.3). Найденный XML-файл правил загрузим в узел обмена или используем для дальнейшей доработки.

Шаг 3. Локализация ошибки через обработку «Универсальный обмен данными в формате XML»

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

1. Откроем в УТ 10.3 типовую обработку Универсальный обмен данными в формате XML.
2. На вкладке Выгрузка данных укажем путь к файлу правил конвертации.
3. На вкладке Параметры выгрузки обязательно включим флаг Записывать в протокол сообщения об ошибках и укажем путь к текстовому файлу журнала.
4. Выберем для выгрузки только один тестовый вид документов (например, сняв отметки со всех правил выборки данных, кроме одного документа).
5. Нажмем кнопку Выгрузить данные.

Если в процессе формирования XML возникнет исключение, обработка моментально прервет операцию и запишет в протокол точное имя правила конвертации объекта (ПКО) или правила конвертации свойства (ПКС), на котором споткнулся процесс.

Шаг 4. Настройка отладки обработчиков правил в «Конвертации данных»

Если текстового описания ошибки в протоколе недостаточно, воспользуемся штатным механизмом отладки правил КД 2.1. Разберем этот процесс по шагам:

1. Откроем конфигурацию Конвертация данных, редакция 2.1 и загрузим в нее XML-файл наших правил обмена.
2. Обновим структуру метаданных: выгрузим с помощью встроенной обработки MD83Exp.epf актуальную структуру конфигураций УТ 10.3 и БП 3.0, после чего загрузим их в базу конвертации.
3. Перейдем в меню настройки выгрузки правил и выберем режим выгрузки с формированием внешнего модуля отладки (создается файл внешней обработки или модуль с программным кодом всех обработчиков ПКО, ПКС и ПВД).
4. Вернемся в базу-источник (УТ 10.3), откроем Универсальный обмен данными в формате XML, перейдем на вкладку Отладка выгрузки и подключим сгенерированный файл отладчика.
5. Откроем конфигуратор рабочей базы УТ 10.3, установим точку останова в проблемном алгоритме или внутри внешней обработки отладчика и запустим процесс выгрузки в режиме отладки платформы. Это позволит пошагово отследить значения переменных в момент возникновения исключительной ситуации.

Шаг 5. Корректировка правил и отключение проблемных реквизитов

Посмотрим на примеры исправления типовых проблем в правилах через конфигурацию Конвертация данных:

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

   
   // Пример проверки, вызывающей остановку обмена
   Если Найти(Строка(Метаданные.Версия), "3.0.44") = 0 Тогда
       ВызватьИсключение "Неподдерживаемая версия конфигурации-приемника!";
   КонецЕсли;
   

   Скорректируем условие под наш фактический номер конфигурации или временно отключим проверку.

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

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