← На главную

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

Как добавленные реквизиты оказываются в объекте «на замке»

Проанализируем основные технические сценарии, приводящие к такой картине в дереве метаданных:

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

Технические риски и последствия некорректной настройки поддержки

Мнение о том, что возврат замка на доработанный объект абсолютно безопасен, является ошибочным. Рассмотрим риски, с которыми можно столкнуться при эксплуатации такой базы:

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

Как правильно настроить правила поддержки

Разберем по шагам, как привести состояние метаданных в порядок в зависимости от стоящей задачи.

Вариант 1. Реквизиты нужны и должны сохраняться при обновлениях:

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

Вариант 2. Реквизиты добавлены по ошибке и не содержат нужных данных:

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

Альтернативные способы доработки без снятия объектов с поддержки

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

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