← На главную

При работе с распределенными информационными базами (РИБ) в 1С:Предприятие иногда возникает ситуация, когда изменения конфигурации, внесенные в центральном узле, не удается применить в периферийной базе через стандартный файл обмена. Чтение сообщения вываливается с ошибкой вроде «Ошибка преобразования значения», а повторные попытки обмена застревают, так как центральный узел при каждом сеансе упорно пытается передать структуру метаданных.

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

Анализ причины: почему центральный узел продолжает отправлять изменения

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

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

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

Правильный порядок действий для восстановления синхронизации

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

Разберем весь процесс по шагам:

1. Выгрузка конфигурации из главного узла: В центральной базе откроем Конфигуратор и выгрузим актуальную конфигурацию в файл (меню Конфигурация → Выгрузить конфигурацию в файл...).
2. Отвязка периферийной базы от главного узла: В периферийной базе необходимо временно снять признак подчинения главному узлу. Это можно сделать программно с помощью обработки или через внешнее соединение: ПланыОбменов.УстановитьГлавныйУзел(Неопределено); Или запустив Конфигуратор периферийной базы с параметром командной строки /ResetMasterNode.
3. Загрузка конфигурации: В режиме Конфигуратора периферийной базы выберем пункт Конфигурация → Загрузить конфигурацию из файла... и укажем сохраненный .cf файл из центральной базы. Важно: нужно использовать именно полную загрузку, а не сравнение/объединение или простое обновление, чтобы гарантировать совпадение всех UUID и контрольного хеша.
4. Применение изменений БД: Обновим конфигурацию базы данных (клавиша F7).
5. Восстановление связи с главным узлом: Вернем периферийной базе статус подчиненного узла. Для этого выполним код:
   Скопировать код

   
   ГлавныйУзел = ПланыОбменов.ГлавныйУзел(); // Если узел сохранен
   // Или находим ссылка на главный узел в плане обмена:
   УзелЦУ = ПланыОбменов.ПоМесяцам.НайтиПоКоду("ЦУ");
   ПланыОбменов.УстановитьГлавныйУзел(УзелЦУ);
   

6. Формирование ответного пакета: В режиме 1С:Предприятие периферийной базы запустим процедуру синхронизации и выгрузим файл обмена. В этот файл заложится номер принятого сообщения и актуальный хеш конфигурации.
7. Загрузка ответа в центральном узле: Перенесем полученный файл в центральную базу и выполним чтение данных. Центральный узел зафиксирует квитанцию и автоматически снимет регистрацию изменений конфигурации для данного узла.

Альтернативные подходы к организации обмена

Рассмотрим ситуацию, когда доставка обновлений конфигурации средствам РИБ затруднена из-за каналов связи или специфики работы. В этом случае часто применяются альтернативные архитектурные решения.

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

1. Снять признак РИБ у плана обмена или добавить отдельный план обмена без флага РИБ.
2. Настроить правила конвертации данных (через механизмы КД2 или КД3 / EnterpriseData).
3. Обмениваться исключительно данными (документами, справочниками, регистрами), а обновление конфигураций на периферийных точках производить штатной загрузкой файла .cf во время плановых технических окон.

Таким образом, мы исключим ситуации, при которых из-за одной ошибки в структуре метаданных полностью останавливается движение оперативных документов между филиалами.