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

← На главную

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

Причины проблемы: почему объекты теряют замок?

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

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

Способ 1. Массовый сброс правил через настройку поддержки (Рекомендуемый способ)

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

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

Этот способ позволяет вернуть «замки» на все неизмененные объекты за один проход, сохранив при этом все уникальные идентификаторы (UUID) метаданных и физические данные в таблицах СУБД.

Опасности «быстрых» альтернативных методов: почему нельзя использовать чистую базу

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

Проанализируем, почему этот метод крайне опасен и категорически не рекомендуется для баз с реальными данными:

Задвоение предопределенных данных: При создании чистой базы и последующем добавлении предопределенных элементов (например, в планах счетов, планах видов характеристик или справочниках) платформа генерирует для них новые внутренние идентификаторы (GUID). При загрузке такого файла в рабочую базу старые предопределенные элементы могут потерять связь со своими физическими объектами в режиме предприятия, что приведет к появлению битых ссылок вида <Объект не найден> или к непредсказуемому дублированию данных.
Потеря уникальных идентификаторов метаданных: Метод полной загрузки стороннего файла конфигурации заменяет внутреннюю структуру метаданных СУБД. Если в новой конфигурации GUID объектов не совпадают с рабочей базой, платформа воспримет это как удаление старых объектов и создание новых. В результате при обновлении конфигурации базы данных будут полностью очищены таблицы соответствующих объектов (будут потеряны данные документов, справочников, регистров).

Влияние версий платформы на рекурсивную установку правил

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

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

Начиная с версий платформы 8.3.13 и выше, это поведение было исправлено. Теперь конфигуратор корректно игнорирует добавленные пользователем объекты при массовом изменении правил для родительских веток метаданных.

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

Способ 2. Автоматизация через выгрузку конфигурации в файлы XML

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

При выгрузке конфигурации в файлы Xml с помощью стандартной команды платформы:


"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /F "ПутьКБазе" /N "Администратор" /P "Пароль" /DumpConfigToFiles "C:\Distr\XmlConfig"

Платформа создает каталог с текстовыми и XML-файлами, описывающими структуру конфигурации. За настройки поддержки в этой структуре отвечает бинарный файл ParentConfigurations.bin (или Configuration.ParentConfigurations.bin в зависимости от формата выгрузки). Этот файл представляет собой сериализованный текстовый массив данных в специальном формате 1С, содержащий соответствие GUID объектов конфигурации правилам их поддержки.

Разберем алгоритм автоматического изменения правил через файлы:

Выгружаем конфигурацию рабочей базы в файлы XML.
С помощью утилиты сравнения файлов (или команды платформы -getChanges) получаем точный список файлов метаданных, которые подверглись реальным изменениям со стороны разработчика.
Используя специализированные скрипты автоматизации (например, на языке OneScript с привлечением библиотек парсинга структуры поддержки, таких как supportconf), программно открываем файл ParentConfigurations.bin.
Скрипт обходит структуру файла и для всех объектов конфигурации, файлы которых не были изменены, принудительно прописывает флаг правила поддержки, соответствующий значению «Не редактируется» (замочек).
Загружаем модифицированные файлы обратно в базу данных с помощью команды:


"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /F "ПутьКБазе" /N "Администратор" /P "Пароль" /LoadConfigFromFiles "C:\Distr\XmlConfig"

Этот способ позволяет мгновенно восстановить статус поддержки для тысяч объектов на серверах непрерывной интеграции (CI/CD) без участия программиста.

Влияние статуса «Не редактируется» на производительность обновления

Среди разработчиков часто ведется дискуссия: ускоряет ли установленный «замок» на объектах процесс сравнения и объединения при обновлении на новые релизы?

Проанализируем этот вопрос глубже. Физические тесты показывают, что время самого процесса сравнения конфигураций (которое запускается при обновлении) практически не меняется в зависимости от того, стоят ли замки на неизмененных объектах или они находятся в статусе «Редактируется с сохранением поддержки». Платформа в любом случае производит побайтовое сравнение метаданных для выявления расхождений.

Однако статус «Не редактируется» дает колоссальные преимущества в других аспектах:

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

Резюме

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