Рассмотрим распространенную ситуацию, с которой сталкиваются разработчики при поддержке нетиповых или частично измененных баз 1С. Вы пытаетесь обновить конфигурацию (в нашем случае 1С:Бухгалтерия), которая подключена к хранилищу и находится на поддержке с возможностью редактирования. В процессе обновления система прерывает работу и выдает сообщение: «Невозможно обновление объектов. Выполнение обновления объектов приведет к снятию данных с поддержки. Повторите обновление после обеспечения доступности объектов для редактирования».
При этом система просит снять с поддержки типовые модули, которые вы никогда не трогали. Разберем по шагам, почему так происходит, проанализируем частые ошибки новичков и выясним правильные алгоритмы обновления конфигураций, подключенных к хранилищу.
Проанализируем ситуацию под капотом платформы. Истинная причина кроется в конфликте механизмов поддержки и хранилища конфигурации.
Когда вы запускаете обновление, платформа 1С видит, что в новом релизе от поставщика (например, фирмы «1С») есть изменения для типовых модулей. Однако ваша текущая база подключена к хранилищу, и эти модули в данный момент не захвачены вашим пользователем. Следовательно, они защищены от записи — на них висит замок хранилища.
Платформа не имеет возможности штатно обновить заблокированный объект. Не понимая, как пробиться через блокировку хранилища, система предлагает радикальный шаг — просто снять этот объект с поддержки поставщика, чтобы получить над ним контроль. Соглашаться на это ни в коем случае нельзя, иначе вы потеряете возможность автоматического обновления этих объектов в будущем.
На многих форумах можно встретить советы вроде: «подготовь обновленный файл конфигурации и просто сделай сравнение и объединение с рабочей базой». Рассмотрим подробнее, почему этот путь крайне опасен.
Механизм СравнитьИОбъединитьСКонфигурациейИзФайла категорически не рекомендуется использовать для накатывания официальных релизов поставщика. Такое объединение игнорирует внутренние идентификаторы объектов конфигурации поставщика. Визуально в дереве метаданных объекты обновятся, код изменится на актуальный, но невидимая связь с конфигурацией поставщика будет разорвана или повреждена.
Если вы пойдете этим путем, в дальнейшем база перестанет корректно обновляться типовыми методами. Чтобы вернуть такую «сломанную» базу на полноценную поддержку, придется проходить сложную и долгую процедуру сравнения с чистым файлом cf разработчика через настройки поддержки.
Посмотрим на правильный и безопасный порядок действий, который используют опытные разработчики. Суть метода заключается в полном предварительном захвате всех объектов конфигурации.
Конфигурация -> Поддержка -> ОбновитьКонфигурацию, выбрав нужный файл cfu или cf.Если конфигурация очень большая (например, 1С:ERP) и рекурсивный захват длится часами или падает с ошибками сети, рассмотрим альтернативный рабочий путь.
ХранилищеКонфигурации -> ОтключитьсяОтХранилища).cf (меню Конфигурация -> СохранитьКонфигурациюВФайл).cf через Конфигурация -> ЗагрузитьКонфигурациюИзФайла (или через объединение, если нужно сохранить ваши текущие незафиксированные доработки, но делать это нужно крайне осторожно).Проанализируем современный подход, который позволяет вообще избегать подобных проблем. Если ваша конфигурация находится на поддержке с возможностью редактирования, подумайте о переносе всех кастомных доработок в Расширения конфигурации.
Вынесение добавленных документов, измененных форм и кастомного кода в расширения позволит вернуть основную конфигурацию на полную поддержку (сделать ее нередактируемой — «желтый кубик с замком»).
В этом случае вам вообще не придется подключать основную конфигурацию к хранилищу для редактирования. База будет обновляться автоматически, без конфликтов и ошибок в пару кликов. А само хранилище конфигурации будет использоваться исключительно для командной разработки самого расширения. Это значительно ускоряет процесс обновления и снижает риски поломки архитектуры базы данных.