← На главную

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

Выясним причину возникновения проблемы

Проанализируем техническую сторону процесса поставки конфигурации. При создании собственного файла поставки платформа 1С автоматически генерирует новый внутренний идентификатор (GUID) поставщика и конфигурации. После загрузки такого файла в рабочую информационную базу происходит следующее:

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

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

Способ 1. Восстановление через снятие с поддержки и сравнение/объединение

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

Важное условие: Перед выполнением любых операций с конфигурацией обязательно создайте полную резервную копию информационной базы (файл .dt или выгрузку базы данных на сервере SQL).

1. Откроем рабочую базу в режиме «Конфигуратор».
2. Перейдем в меню Конфигурация — Поддержка — Настройка поддержки.
3. В окне настройки поддержки нажмем кнопку Снять с поддержки и подтвердим операцию.
4. Подготовим файл оригинальной поставки .cf ровно того же релиза, который сейчас установлен в рабочей базе (выгруженный из чистой типовой базы 1С или взятый из официального дистрибутива).
5. Откроем меню Конфигурация — Сравнить, объединить с конфигурацией из файла и выберем подготовленный файл .cf.
6. На вопрос платформы о постановке конфигурации на поддержку ответим Да.
7. В появившемся окне сравнения и объединения объектов снимем абсолютно все флажки со всех объектов метаданных, чтобы не перезаписать доработки основной конфигурации.
8. В окне настройки правил поддержки установим для типовых объектов правило Редактируется с сохранением поддержки, а для пользовательских (собственных) объектов — Объект снят с поддержки.
9. Выполним объединение, сохраним основную конфигурацию и обновим конфигурацию базы данных (клавиша F7).

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

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

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

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

Ограничения платформы и ключевые риски

Разберем основные риски, о которых важно помнить при выполнении подобных операций:

Риск реструктуризации и удаления данных: Категорически не рекомендуется использовать команду Конфигурация — Загрузить конфигурацию из файла на рабочей базе с пользовательскими объектами. Операция загрузки сопоставляет объекты метаданных исключительно по их внутренним идентификаторам (UUID). Если созданные объекты в рабочей базе и файл .cf имеют разные UUID, платформа посчитает существующие объекты удаленными, а объекты из файла — новыми. В результате реструктуризации таблицы базы данных будут очищены, что приведет к безвозвратной потере данных.

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

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

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

1. Хранилище конфигурации 1С: Для совместной разработки и переноса изменений между базами следует использовать штатный механизм Хранилища конфигурации. Он корректно сохраняет UUID объектов и не меняет конфигурацию поставщика.
2. Механизм расширений (`.cfe`): Все пользовательские объекты и алгоритмы рекомендуется выносить в расширения конфигурации. Это позволяет оставить основную конфигурацию полностью типовой (на строгой поддержке), что делает последующие обновления автоматическими и безопасными.