← На главную

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

Основные причины блокировки обновления

Проанализируем ключевые факторы, из-за которых платформа 1С:Предприятие запрещает автоматическое обновление объектов:

1. Неоднородные правила поддержки в дереве метаданных. Часто родительский объект (например, справочник) имеет статус Объект поставщика редактируется с сохранением поддержки, но его подчиненные реквизиты, табличные части или формы унаследовали статус Не редактируется (без права редактирования). В этом случае накат изменений на подчиненный реквизит блокируется.
2. Конфликт нескольких конфигураций поставщика. Если в конфигурацию внедрен сторонний модуль (например, подсистема интеграции или отраслевое решение) и база находится на поддержке двух и более поставщиков, обновление одной конфигурации может затрагивать заблокированные объекты другой.
3. Блокировка объектов в Хранилище конфигурации. Если информационная база подключена к хранилищу конфигурации, для выполнения обновления все изменяемые метаданные и корень конфигурации должны быть захвачены текущим пользователем. Если объект захвачен другим разработчиком или не захвачен вовсе, обновление будет прервано.

Способ 1. Каскадная настройка правил поддержки для подчиненных объектов

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

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

Способ 2. Отмена захвата и корректная подготовка Хранилища конфигурации

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

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

Способ 3. Корректировка сопоставления при наличии двух конфигураций поставщика

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

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

Рекомендации по оптимизации архитектуры базы данных

Чтобы в дальнейшем минимизировать проблемы при обновлении нетиповых конфигураций, рассмотрим современные подходы к архитектуре 1С:

1. Использование расширений конфигурации (CFE). Все доработки, собственные реквизиты и сторонние модули рекомендуется выносить в расширения. Это позволяет оставить основную конфигурацию на полной типовой поддержке без включения возможности изменения, что полностью исключает конфликты правил поддержки при наложении релизов.
2. Регулярный аудит правил поддержки. При снятии объектов с поддержки всегда следует явно определять область действия правил для дочерних реквизитов, чтобы избежать частичной блокировки структуры метаданных.