← На главную

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

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

Причина 1. Объект входил в состав удаляемого плана обмена (статус «Регистрация изменена»)

Проанализируем, что именно происходит на уровне базы данных, когда мы удаляем ПланОбмена или исключаем из его состава определенные типы метаданных.

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

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

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

Важно понимать: данное системное сообщение не означает, что данные в самом справочнике (наименования, курсы валют, коды) были повреждены или перезаписаны. Это лишь уведомление о том, что платформа изменила служебные таблицы регистрации изменений для данного объекта.

Причина 2. Очистка составных типов данных (ЛюбаяСсылка, СправочникСсылка)

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

Если в объекте (например, в справочнике Справочник.Валюты или в связанном с ним регистре сведений) присутствуют реквизиты со следующими типами данных:

1. ЛюбаяСсылка — универсальный ссылочный тип, включающий в себя ссылки абсолютно на все существующие объекты метаданных конфигурации.
2. СправочникСсылка или ДокументСсылка — составные типы, агрегирующие все справочники или документы.
3. Пользовательские составные типы — реквизиты, в состав которых разработчики вручную включили типы удаляемых справочников или документов.

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

Причина 3. Функциональные опции, подсистемы и командный интерфейс

Проанализируем неявные метаданные, влияющие на состояние объектов конфигурации:

1. Функциональные опции: Если справочник или его реквизиты были привязаны к функциональной опции, входящей в удаляемый модуль, удаление опции влечет автоматическое удаление ссылки на нее из свойств самого справочника.
2. Принадлежность к подсистемам: Удаление подсистемы или снятие флагов включения объекта в подсистему изменяет коллекцию состава подсистем, что регистрируется как модификация объекта.
3. Роли и права доступа: При удалении специализированных ролей из конфигурации платформа пересчитывает общую матрицу прав, затрагивая права чтения и записи всех объектов.

Причина 4. Изменение порядка следования объектов в дереве метаданных

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

Пошаговый алгоритм: как точно узнать, что именно изменилось в объекте

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

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

Практические рекомендации и риски при обновлении

Разберем важные нюансы, которые необходимо учитывать при проведении реструктуризации базы данных:

1. Резервное копирование: Перед применением изменений (особенно при массовом удалении подсистем и планов обмена) всегда создаем выгрузку информационной базы в файл .dt или делаем резервную копию средствами SQL-сервера.
2. Потеря зарегистрированных изменений: Помним, что удаление плана обмена безвозвратно стирает все накопившиеся изменения по объектам в его узлах. Если справочник Справочник.Валюты параллельно участвует в других обменах (например, с конфигурацией «1С:Бухгалтерия предприятия»), убедимся, что удаляется только узел Битрикса, а рабочие планы обмена не затронуты.
3. Монопольный режим: Удаление служебных таблиц _ChangeRec и реструктуризация больших таблиц требуют блокировки базы данных. Выполнять такие процедуры следует в период минимальной активности пользователей.