← На главную
При работе с распределенной информационной базой (РИБ) в 1С:Управление торговлей 10.3 специалисты часто сталкиваются с ситуацией, когда изменения, внесенные в конфигурацию головного узла (например, добавление новых ставок НДС или изменение структуры справочников), не передаются на подчиненные узлы. Выполняется обычный обмен, документы и элементы справочников мигрируют успешно, но метаданные остаются прежними, а конфигурация для изменения не выгружается. Давайте подробно разберем эту ситуацию и выясним причину такого поведения платформы.
В каком виде конфигурация передается в файле обмена?
Многие ожидают увидеть добавленные объекты конфигурации в файле обмена XML в виде обычных тегов, как это происходит с данными справочников или документов. Однако платформа работает иначе. Проанализируем структуру файла обмена:
- Изменения конфигурации помещаются в XML-файл не в виде открытых тегов метаданных, а в виде зашифрованной строки (большого бинарного блока) внутри файла.
- В заголовке файла обмена фиксируется хэш конфигурации. Если хэш изменился, система понимает, что вместе с данными передается и новая структура метаданных.
- В старых версиях конфигураций на обычных формах, к которым относится УТ 10.3, выгрузка конфигурации происходит монолитно. Платформа передает не «разницу» внесенных изменений, а запакованный слепок конфигурации целиком. Из-за этого файл обмена может достигать сотен мегабайт.
Основные причины, почему метаданные не выгружаются
Рассмотрим подробнее, почему файл обмена может не содержать долгожданного обновления конфигурации:
- Изменения не применены к базе данных: Внесенные изменения могли остаться только в основной конфигурации. Если в конфигураторе главного узла не была нажата клавиша F7 (или кнопка «Обновить конфигурацию базы данных»), метаданные не зарегистрируются для выгрузки.
- Использование динамического обновления: Если изменения применялись динамически (без монопольного доступа), механизм РИБ может некорректно зарегистрировать их. В РИБ динамическое обновление часто является причиной рассинхронизации.
- Рассинхронизация номеров сообщений: Если предыдущее сообщение с изменениями было сформировано, но не загружено в подчиненную базу, либо в центр не вернулась квитанция об успешном приеме, платформа не будет повторно вкладывать метаданные в новые файлы обмена.
- Превышение лимитов передачи данных: Из-за того, что слепок конфигурации весит много, при обмене по почте или FTP файл может обрезаться провайдером из-за ограничений на размер вложения.
Способы решения проблемы
Разберем по шагам несколько рабочих методов, которые помогут протолкнуть изменения на периферийные узлы.
Способ 1. Принудительное изменение хэша и очистка кэша
Если изменения зависли и не регистрируются на узле, мы можем заставить платформу принудительно обновить хэш и сформировать пакет заново. Выполним следующие действия:
- Зайдите в Конфигуратор главного узла.
- Добавьте любой фиктивный объект (например, новую Константу с произвольным именем).
- Нажмите F7, чтобы обновить конфигурацию базы данных. Это гарантированно изменит хэш конфигурации.
- Обязательно очистите кэш 1С на компьютере, где выполняется обмен.
- Запустите обмен данными.
Способ 2. Сброс регистрации сообщений обмена
Если произошла рассинхронизация номеров, можно принудительно заставить систему выгрузить все данные заново. Для этого в настройках узла на стороне центральной базы измените номера принятых и отправленных сообщений на нули или на значения меньше текущих. При следующем обмене будет сформирован полный пакет выгрузки, включая конфигурацию.
Способ 3. Ручной перенос конфигурации (гарантированный резервный вариант)
Если стандартный обмен не справляется из-за объема файла или системных сбоев, воспользуемся проверенным способом ручного обновления подчиненного узла. Посмотрим на алгоритм действий:
- В Конфигураторе главного узла выгрузите файл конфигурации через меню: Конфигурация — Сохранить конфигурацию в файл (сохраните в формате
.cf).
- Передайте этот файл на точку, где находится периферийная база.
- Временно отключите признак РИБ в подчиненном узле. Это можно сделать двумя путями:
- Запустить периферийную базу из командной строки с параметром
/ResetMasterNode.
- Или запустить базу в режиме Предприятия и программно выполнить следующий код в любой обработке:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
- После отвязки узла откройте Конфигуратор подчиненной базы. Выберите меню Конфигурация — Загрузить конфигурацию из файла и укажите переданный
.cf файл.
- Обновите конфигурацию базы данных (клавиша F7).
- Верните привязку к главному узлу. Для этого выполните код, указав ссылку на нужный узел:
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавныйУзел);
После выполнения этих шагов структура баз снова станет абсолютно идентичной, и обычный обмен данными через РИБ успешно возобновится.
Альтернативные подходы к обмену
Механизм классического РИБ жестко требует абсолютной идентичности структуры метаданных. Если магазины или филиалы находятся на нестабильных каналах связи, передача огромных файлов конфигурации каждый раз при добавлении реквизита становится проблемой.
В качестве альтернативы для старых систем вроде УТ 10.3 можно рассмотреть отказ от РИБ в пользу обмена по правилам через Универсальный обмен данными в формате XML (используя конфигурацию Конвертация данных 2.0). В этом случае базы становятся независимыми, и вы можете вносить небольшие доработки (например, локальные ставки НДС или свои печатные формы) в узлы без риска заблокировать работу обмена из-за несовпадения метаданных. Также в современных конфигурациях активно используется синхронизация через универсальный формат EnterpriseData (ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат), которая решает схожие задачи более элегантно.