Как восстановить конфигурацию поставщика и вернуть объекты на поддержку под замок

← На главную

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

Анализируем причины некорректного поведения поддержки

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

Ошибки релизов платформы: В линейках 8.3.19.х и 8.3.20.х был зафиксирован баг, при котором визуальное отображение статуса поддержки не соответствовало реальному состоянию БД. Платформа некорректно записывает изменения в служебные таблицы Config или ConfigSave.
Разрыв связи (UUID): Если конфигурация когда-либо обновлялась некорректно (например, через «Загрузить конфигурацию из файла» вместо «Сравнить, объединить с конфигурацией поставщика»), внутренние идентификаторы объектов основной конфигурации могут перестать совпадать с идентификаторами в конфигурации поставщика.
Влияние расширений: В некоторых версиях платформы наличие расширения, затрагивающего объект, может визуально изменять отображение «замка» в дереве метаданных, даже если в основной конфигурации объект не менялся.
Кэширование метаданных: Существует не только локальный кэш пользователя, но и серверный кэш (в папке snccntx), который может хранить устаревшие состояния объектов.

Метод 1. Возврат на поддержку через «Настройку поддержки» (стандартный)

Рассмотрим пошагово наиболее правильный способ восстановления статуса без полной перезаписи всей конфигурации. Посмотрим на примере справочника Валюты.

Выполним следующие действия:

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

Метод 2. Радикальное восстановление через файл конфигурации (.cf)

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

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

Метод 3. Исправление «фантомных» изменений и логической целостности

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

Выполним Тестирование и исправление (ТиИ). Нам интересен конкретный пункт: «Проверка логической целостности конфигурации». Проанализируем ситуацию: этот механизм проверяет соответствие метаданных их физической структуре в таблицах базы. Часто после выполнения этой проверки «фантомные» изменения исчезают.

Также полезно выполнить процедуру «фиктивного обновления»:

Зайдем в Конфигурация — Поддержка — Обновить конфигурацию.
Выберем «Выбор файла обновления» и укажем тот же самый релиз .cf (или .cfu), который установлен сейчас.
Платформа проведет полную ревизию всех объектов и восстановит структуру поддержки, если она была нарушена.

Очистка серверного кэша при устойчивых ошибках

Если вы работаете в клиент-серверном варианте и визуальные глюки с поддержкой продолжаются даже после манипуляций с .cf, разберем процедуру очистки серверного кэша. Помните, что обычная очистка папок в %AppData% на компьютере пользователя здесь не поможет.

Пошаговый план для системного администратора:

Остановить службу сервера 1C:Enterprise 8.3.
Перейти в каталог с данными сервера (обычно это C:\Program Files\1cv8\srvinfo).
Найти папку конкретной информационной базы по её UID.
Внутри неё найти и удалить содержимое папок snccntx и config8.
Запустить службу сервера.

После этой процедуры платформа будет вынуждена заново пересчитать кэш метаданных из таблиц базы данных, что часто решает проблему «невидимых» изменений или неверных статусов поддержки.