Как обновить нетиповую конфигурацию 1С при рассинхронизации версий с конфигурацией поставщика?

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

Почему возникает рассинхронизация версий конфигураций

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

Рассинхронизация версий возникает в следующих случаях:

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

Как локализовать реальные изменения в коде

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

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

Посмотрим на пример локализации изменений. Зачастую в отчете о сравнении среди добавленных типовых объектов находится всего один скорректированный модуль. Например, в общем модуле ОбщийМодуль.ПрефиксацияОбъектовКлиентСервер может быть добавлена кастомная строка управления префиксами:

// Пример пользовательской доработки в типовом модуле
УдалитьПрефиксИнформационнойБазы = Истина;

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

Пошаговое восстановление конфигурации поставщика

Разберем по шагам правильный алгоритм приведения структуры поддержки к эталонному состоянию.

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

Риски пропуска промежуточных релизов и запуск обработчиков обновления

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

Чтобы инициировать корректное выполнение процедур обновления данных:

1. Выполним синтаксический контроль модулей и проверку логической целостности через Конфигурация — Проверка конфигурации.
2. Запустим информационную базу в режиме «1С:Предприятие» с параметром командной строки: /C ЗапуститьОбновлениеИнформационнойБазы
3. Проверим протокол выполнения процедур обновления в журнале регистрации или через специализированную форму регламентных и фоновых заданий БСП.
4. Выполним тестирование и исправление информационной базы через меню Администрирование — Тестирование и исправление, обязательно отметив пункты проверки логической и ссылочной целостности, а также реиндексацию таблиц.

Как избежать снятия с поддержки в будущем

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