Как исправить ошибку «Данные принимаются от узла, для которого зарегистрированы изменения конфигурации» в РИБ 1С

← На главную

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

«Ошибка чтения файла сообщения обмена... Данные принимаются от узла, для которого зарегистрированы изменения конфигурации. Необходимо произвести перенос изменений конфигурации в узел».

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

Выясняем причину: как устроена регистрация изменений конфигурации

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

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

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

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

Разбираем структуру XML-файла обмена

Проанализируем заголовок файла сообщения обмена, который формируют базы. Если открыть файл обмена (XML) в текстовом редакторе, мы увидим следующие ключевые параметры в блоке заголовка:

Хэш внутри тега Digest1 или Digest2 (например, d41d8cd98f00b204e9800998ecf8427e) — это контрольная сумма схемы метаданных. Если метаданные в обеих базах совпадают (что подтверждается сравнением конфигураций), этот хэш будет одинаковым.
Параметр v2 — это уникальный идентификатор (UUID) конкретного поколения сборки конфигурации базы данных. Этот параметр изменяется при каждом обновлении конфигурации базы данных в Конфигураторе, даже если вы просто зашли, добавили пробел в комментарий кода и нажали «Обновить конфигурацию базы данных» (F7).
Параметр Extensions — отражает контрольную сумму подключенных расширений конфигурации.

Различие в значениях параметра v2 (например, в ЦБ указано 0f6e26b75bc66a05cdcfe4c397d75f62, а в ПБ — e24e0c39fcae7c07fb4079a25b228918) сообщает платформе, что базы находятся на разных «жизненных этапах» развития конфигурации. Чаще всего это происходит из-за так называемого динамического обновления (когда конфигурация обновляется без завершения работы пользователей). Платформа фиксирует «демоническое» обновление конфигурации, кэш на сервере обновляется некорректно, поколения сборки расходятся, и обмен блокируется.

Ниже рассмотрим несколько эффективных способов решения данной проблемы — от самых простых и безопасных до продвинутых инженерных методов.

Способ 1. Прямая очистка таблицы регистрации через SQL (для клиент-серверных ЦБ)

Если ваша центральная база работает в клиент-серверном режиме под управлением СУБД (MS SQL Server, PostgreSQL и др.), это самый быстрый, надежный и чистый способ решения проблемы. Мы просто удалим записи о регистрации изменений конфигурации напрямую из СУБД.

Выполним следующие шаги:

Обязательно создадим резервную копию центральной базы данных перед проведением любых манипуляций на уровне СУБД!
Запустим утилиту управления вашей СУБД (например, SQL Server Management Studio для MS SQL или pgAdmin для PostgreSQL).
Нам нужно очистить системную таблицу регистрации изменений конфигурации. Для этого выполним следующий SQL-запрос к базе данных ЦБ:


-- Вариант 1. Очистить регистрацию конфигураций для ВСЕХ узлов РИБ сразу:
TRUNCATE TABLE _ConfigChngRec;

Если в вашей системе зарегистрировано много периферийных узлов и вы хотите сбросить регистрацию только для одного конкретного «проблемного» узла, воспользуемся вторым вариантом запроса:


-- Вариант 2. Очистить регистрацию только для определенного узла:
DELETE FROM _ConfigChngRec WHERE NodeID = [Идентификатор_Узла_ПБ];

Где [Идентификатор_Узла_ПБ] — это внутренний уникальный идентификатор узла периферийной базы в СУБД. После успешного выполнения этого запроса Центральная база моментально «забудет» о том, что для ПБ регистрировались какие-либо изменения конфигурации, и успешно загрузит файл обмена от ПБ при первом же сеансе.

Способ 2. Пересоздание узла обмена в ЦБ без потери данных

Если у вас нет прямого доступа к СУБД или центральная база является файловой, предыдущий способ применить не получится. В таком случае мы можем стереть историю конфигурационных расхождений путем пересоздания узла обмена в ЦБ.

Разберем этот процесс по шагам:

В центральной базе перейдем в справочник настроек вашего плана обмена. Откроем карточку проблемного периферийного узла и обязательно запишем (или сохраним на скриншоте) его точный Код и Наименование. Эти данные критически важны для последующего сопоставления.
Пометим данный периферийный узел на удаление.
Перейдем в меню «Администрирование» — «Удаление помеченных объектов» и удалим этот узел непосредственно. При физическом удалении элемента плана обмена платформа 1С автоматически полностью очистит все связанные с ним таблицы регистрации изменений в базе данных (включая регистрацию изменений данных и конфигурации).
Теперь создадим новый узел в этом же плане обмена. Пропишем ему точно такие же Код и Наименование, какие были у удаленного узла.
Поскольку мы создали новый узел, счетчик сообщений сбросился. Откроем стандартную обработку «Регистрация изменений для обмена» (ее можно открыть через функции для технического специалиста). Для нашего нового узла скорректируем номера сообщений: установим «Номер отправленного» и «Номер принятого» сообщения в соответствие с теми номерами, которые зафиксированы на стороне ПБ (или сбросим их в «0» на обеих сторонах обмена).

После этого запустим обмен. Проблема будет полностью решена, так как все устаревшие системные записи регистрации конфигурации были удалены вместе со старым узлом.

Способ 3. Преодоление ошибки «Искажены изменения конфигурации» через правку XML

Иногда специалисты пытаются вручную изменить параметры хэша и UUID конфигурации в XML-файле, но при загрузке сталкиваются с ошибкой «Искажены изменения конфигурации!». Это происходит из-за того, что в заголовке сообщения от ЦБ содержатся не только строковые хэши, но и сжатые бинарные файлы самого обновления метаданных, если они были выгружены.

Чтобы сделать корректную «заглушку» через ручную правку XML-файла и обмануть систему, выполним следующие действия:

Сформируем и выгрузим «пустой» файл обмена из ПБ в ЦБ. В нем не должно быть никаких изменений конфигурации, только заголовок и измененные данные документов или справочников.
Откроем полученный файл XML в текстовом редакторе (например, Notepad++).
Найдем секцию <v8de:Config>. Нам необходимо вручную привести параметры v2 и Extensions в полное соответствие с тем, что ожидает Центральная база. Для этого откроем последний XML-файл, выгруженный ранее из ЦБ.
Скопируем полностью весь блок конфигурации <v8de:Config> со всеми вложенными свойствами и хэшами из файла ЦБ и заменим им аналогичный блок в заголовке файла обмена, подготовленного для загрузки в ЦБ.
Сохраним изменения в файле обмена ПБ и загрузим его в ЦБ.

При чтении такого файла Центральная база решит, что периферийная база уже успешно применила нужное обновление, имеет идентичное актуальное поколение сборки конфигурации (UUID) и безболезненно снимет блокировку обмена.

Способ 4. Исправление последствий «динамического» обновления

Динамическое обновление конфигурации в ЦБ — это главный источник рассинхронизации РИБ. Кэш базы данных на сервере приложений часто продолжает отдавать старую версию метаданных фоновым заданиям обмена, в то время как пользователи уже работают на новой версии. Чтобы гарантированно исправить последствия динамического обновления без создания новой пустой базы, выполним следующую последовательность действий:

Попросим всех пользователей выйти из центральной базы 1С и завершим все активные сеансы на сервере приложений.
Откроем ЦБ в режиме Конфигуратора.
Внесем любое минимальное, незначительное изменение в конфигурацию. Например, можно открыть любой неиспользуемый общий модуль или модуль управляемого приложения и просто добавить пробел в комментариях к коду, либо создать новую временную константу.
Выполним обновление конфигурации базы данных строго в монопольном режиме (клавиша F7 или кнопка «Обновить конфигурацию базы данных»). Крайне важно сделать это монопольно, избегая динамического обновления!

Этот процесс принудительно перезапишет таблицы метаданных в СУБД, сбросит старый кэш платформы и установит единый актуальный идентификатор версии сборки конфигурации (v2) для всех последующих сеансов обмена.

Способ 5. Очистка кэша конфигурации на сервере 1С

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

Остановим службу сервера «1C:Enterprise 8.3 Server Agent».
Перейдем в каталог на сервере, где хранятся временные файлы службы (по умолчанию для Windows это C:\Program Files\1cv8\srvinfo\reg_1541\).
Найдем внутри папки с GUID вашей базы данных каталоги с именами snccg и config.
Удалим содержимое этих каталогов (это временный кэш конфигурации базы данных).
Запустим службу сервера 1С заново.

После очистки серверного кэша и выполнения штатного цикла обмена (ЦБ -> ПБ -> ЦБ) базы данных успешно синхронизируются без возникновения ошибок метаданных. Для регулярной процедуры можно использовать скрипт для автоматической очистки серверного кэша 1С.