← На главную

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

Почему в базе оказывается несколько конфигураций на поддержке?

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

Ограничения платформы и почему нельзя использовать простое сравнение/объединение

Рассмотрим подробнее, что произойдет, если мы пойдем по пути наименьшего сопротивления и используем механизм сравнения/объединения.

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

Проверенные способы решения: как правильно обновлять

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

1. Последовательное штатное обновление

Это самый надежный базовый сценарий. Процесс запускается поочередно для каждого вендора:

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

2. Использование сводного файла

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

3. Фиктивное обновление (выравнивание конфигурации)

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

Альтернативные варианты и современные подходы

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

Переход на расширения (.cfe)

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

Разделение контуров и интеграция

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