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

В процессе планового обновления конфигураций (например, «1С:Бухгалтерия предприятия» редакции 2.0 или 3.0) администраторы и разработчики часто сталкиваются с системным сообщением о том, что для работы релиза требуется более свежая версия технологической платформы. Дополнительно в базах с включенной возможностью изменения могут возникать коллизии: задвоение регламентированных отчетов (например, 6-НДФЛ) или появление регистров без регистраторов. Рассмотрим подробно, как правильно спланировать переход на новую платформу, настроить совместную работу нескольких информационных баз и корректно разрешить конфликты метаданных при объединении.

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

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

1. Криптография и электронный документооборот: для сдачи отчетности в ФНС, СФР и работы сервиса «1С-Отчетность» используются актуальные криптографические библиотеки и механизмы подписи, поддержанные в ядре платформы.
2. Формирование регламентированных отчетов: расчет сложных форм (таких как расчет по страховым взносам или 6-НДФЛ) требует оптимизированной работы с табличными документами и большими XML-пакетами.
3. Исправление ошибок оптимизации: устранение утечек памяти и нестабильности при динамическом обновлении конфигурации.

Совместная работа нескольких баз на одном сервере

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

1. Режим совместимости: конфигурации на обычных формах (включая БП 2.0 и УПП 1.3) работают в режиме совместимости с платформой 8.2 (например, «Версия 8.2.13» или «Версия 8.2.16»). При установке более новой платформы 8.3 режим совместимости гарантирует исполнение программного кода по старым правилам, что предотвращает сбои в УПП.
2. Развертывание двух служб сервера 1С: если для критически важной базы требуется строго зафиксировать конкретную сборку (например, 8.3.7), на одном физическом сервере создаются две независимые службы ragent. Для второй службы назначаются альтернативные порты кластера: основной порт 1640, менеджер кластера 1641 и диапазон рабочих процессов 1660:1691.

Временный обход проверки версии платформы в экстренной ситуации

Если отчетность необходимо выгрузить срочно, а возможность немедленно обновить серверную платформу отсутствует, разберем временное решение. Проверка версии платформы выполняется программно при старте сеанса или перед открытием обработок обновления.

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

// ПроверкаМинимальнойВерсииПлатформы();
// Временный пропуск проверки для экстренной выгрузки отчетности

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

Устранение дублирования отчетов и удаление неиспользуемых регистров

Посмотрим на ситуацию, когда в конфигурации появляется второй экземпляр регламентированного отчета (например, 6-НДФЛ) или регистр накопления (например, УчетНДСпоОСиНМА) остается без регистраторов. Это происходит в конфигурациях, снятых с полной поддержки, когда объект был добавлен программистом вручную до выхода официального релиза от поставщика. Поскольку внутренние идентификаторы (GUID) ручного объекта и объекта поставщика не совпадают, платформа создает копию.

Разберем по шагам процедуру корректного объединения:

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

Регламентные операции после установки новой платформы

После перехода на новый релиз платформы обязательно выполним следующие действия для предотвращения сбоев:

1. Очистка локального кэша: на клиентских машинах и на сервере очищаем каталоги пользовательского кэша в папках %LOCALAPPDATA%\1C\1Cv8 и %APPDATA%\1C\1Cv8. Это исключает ошибки метаданных и некорректную отрисовку экранных форм.
2. Тестирование и исправление: в режиме «Конфигуратор» запускаем процедуру Администрирование — Тестирование и исправление... с включенными пунктами проверки логической целостности и реиндексации таблиц информационной базы.
3. Проверка планов обмена: если в базе настроена синхронизация данных, проверяем доступность предопределенного узла плана обмена ЭтотУзел, чтобы избежать потери регистрационных номеров сообщений.