Где хранится версия БСП и как её посмотреть

Версию библиотеки стандартных подсистем проще всего посмотреть в конфигураторе: откройте общий модуль ОбновлениеИнформационнойБазыБСП, найдите функцию ВерсияБиблиотеки() — она возвращает строку вида 3.1.10.456. Это и есть версия БСП, на которой собрана ваша конфигурация.

Но есть нюанс, из-за которого вопросы про БСП возникают на ровном месте. Версий на самом деле две, и совпадают они не всегда: версия библиотеки в коде и версия, до которой фактически обновлена информационная база. Какую смотреть — зависит от задачи: для оценки совместимости с расширением нужна версия в коде, для диагностики «почему после обновления что-то отвалилось» — версия базы.

Способ проверки тоже разный в зависимости от доступа. Есть конфигуратор — смотрите модуль. Только режим «1С:Предприятие» — открываете регистр сведений или запускаете внешнюю обработку . Нужно принять решение в коде доработки — сравниваете версии встроенной функцией. Разберём каждый вариант по порядку, а в конце — как сверить номер БСП с требуемой версией платформы.

Две версии БСП, которые путают чаще всего

Прежде чем смотреть номер, определитесь, какой именно вам нужен.

• 📦 Версия библиотеки — та, что «зашита» в коде конфигурации. Её возвращает функция ВерсияБиблиотеки(). Показывает, на какой БСП собрана поставка, которую вы загрузили.
• 🗄️ Версия информационной базы — до какой версии реально обновлена ваша база. Хранится в регистре сведений «Версии подсистем» для подсистемы «СтандартныеПодсистемы».

После корректного обновления обе версии совпадают. Расходятся они в двух ситуациях: конфигурация загружена, но обработчики обновления ещё не отработали (база запускалась в монопольном режиме и обновление прервали), либо базу перенесли из dt без запуска обновления. Если версии разные — сначала завершите обновление базы, а потом уже делайте выводы о совместимости.

Смотрим версию библиотеки в конфигураторе

Самый прямой способ, если у вас есть доступ к конфигуратору.

1. Откройте базу в конфигураторе.
2. В дереве конфигурации раскройте ветку Общие → Общие модули.
3. Найдите модуль ОбновлениеИнформационнойБазыБСП и откройте его.
4. Поиском по модулю (Ctrl+F) найдите функцию ВерсияБиблиотеки.
5. Внутри функции стоит возврат строковой константы — это и есть версия, например Возврат "3.1.10.456";.

Открывать конфигуратор только для просмотра кода безопасно: он не блокирует работу пользователей. Монопольный доступ платформа требует лишь при обновлении структуры базы, загрузке dt, тестировании и исправлении — а просто открыть модуль можно и на работающей базе.

Версия базы в режиме «1С:Предприятие»

Когда конфигуратора под рукой нет, а права администратора есть, версию, до которой обновлена база, покажет регистр сведений «Версии подсистем».

Сначала включите команду «Все функции», если она скрыта:

1. Главное меню (значок в левом верхнем углу) → Сервис → Параметры (в части релизов пункт называется «Настройки»).
2. Отметьте флажок «Отображать команду “Все функции”» и нажмите «ОК».

Дальше откройте сам регистр:

1. Главное меню → Все функции.
2. Раскройте ветку Регистры сведений.
3. Откройте регистр «Версии подсистем».
4. В списке найдите строку, где имя подсистемы — «СтандартныеПодсистемы». В колонке «Версия» стоит нужный номер.

В этом же регистре видны версии других библиотек и подсистем конфигурации — удобно, когда нужно свериться по нескольким сразу. Регистр доступен только пользователю с правами администратора; обычному пользователю команда «Все функции» список регистров не покажет.

Внешняя обработка: проверка без конфигуратора

Этот вариант выручает, когда нет ни доступа к конфигуратору, ни прав на «Все функции», но есть право на открытие внешних обработок. Тогда версию достаёт маленькая обработка в пару строк.

Собрать её несложно — пригодится и как образец для других проверок:

1. В конфигураторе Файл → Новый → Внешняя обработка.
2. Добавьте обработке форму.
3. На форму положите кнопку, а команде кнопки сопоставьте процедуру.
4. В модуле формы — вызов серверной функции БСП (код ниже).
5. Сохраните файл .epf и открывайте его в режиме «1С:Предприятие» через Файл → Открыть.

Серверный вызов в обработчике:

&НаСервере
Процедура ПоказатьВерсиюНаСервере()
    Сообщить("Версия библиотеки БСП: " + ОбновлениеИнформационнойБазыБСП.ВерсияБиблиотеки());
КонецПроцедуры

Кнопка на форме вызывает эту процедуру — версия выводится в окно сообщений. Готовые «обработки проверки версии» ходят по рукам у специалистов, но безопаснее собрать свою: так вы точно знаете, что внутри.

Программный способ: функции БСП в консоли кода

Если задача — получить версию из кода (в консоли кода, в отладчике, в своей обработке), пригодятся встроенные функции БСП.

Версия библиотеки:

Сообщить("Версия БСП в коде: " + ОбновлениеИнформационнойБазыБСП.ВерсияБиблиотеки());

Функция возвращает строку, поэтому её можно спокойно склеивать с текстом через + без дополнительного преобразования. Результат — тот же номер, что лежит в модуле из первого способа.

Когда версий две и нужно их сравнить программно, не сравнивайте строки оператором >: "3.1.10" и "3.1.9" как строки сравниваются посимвольно и дадут неверный результат. Для номеров версий есть специальная функция:

Результат = ОбщегоНазначенияКлиентСервер.СравнитьВерсии("3.1.10.456", "3.1.9.100");
// Результат = 1, если первая версия новее; 0 — равны; -1 — первая старше

Эта же функция — основа для любых проверок «версия не ниже такой-то».

Перед обращением к функциям конкретной подсистемы полезно убедиться, что она вообще встроена в конфигурацию. В БСП для этого есть проверка наличия подсистемы по её полному имени — она возвращает признак «есть/нет», и только при положительном ответе вызывают методы подсистемы. Это страхует код, который должен работать и в урезанных конфигурациях, где часть подсистем отключена.

Журнал регистрации: когда база обновлялась до версии БСП

Журнал регистрации не хранит строку версии БСП — но показывает, когда база обновлялась и накатывались обработчики. Это помогает, когда версии разошлись и надо понять, прошло обновление или оборвалось.

Открыть журнал можно двумя путями:

• в режиме «1С:Предприятие»: Все функции → Стандартные → Журнал регистрации;
• в конфигураторе: меню Администрирование → Журнал регистрации.

Ограничьте период предполагаемого обновления и отфильтруйте записи по событию обновления конфигурации базы данных. По дате последней такой записи вы увидите, когда база реально переходила на новую версию. Саму же строку версии после этого смотрите в регистре «Версии подсистем» — журнал отвечает на вопрос «когда», а не «какой номер».

Этот способ особенно полезен в связке с предыдущими. Если версия библиотеки в модуле выше, чем версия базы в регистре, журнал покажет, был ли вообще запуск обновления после загрузки свежего релиза. Нет записи об обновлении за нужный период — значит, обработчики не отрабатывали, и базу надо запустить так, чтобы обновление прошло до конца.

Совместимость версии БСП с платформой и релизом

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

Сравнивайте версии платформы однозначно — по принципу «не ниже требуемой», а не «старше/младше». Если установленная платформа ниже минимальной для вашей БСП, типовой код начнёт падать на несуществующих методах: какой-нибудь встроенный вызов библиотеки опирается на возможность платформы, которой в старой версии ещё нет. Внешне это выглядит как случайная ошибка в типовом механизме, хотя причина — рассинхрон версий.

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

Отдельно обновить БСП «в отрыве» от конфигурации в типовом решении нельзя: библиотека приходит внутри очередного релиза конфигурации. Самостоятельно поднимают версию БСП только разработчики собственных конфигураций — через механизм поставки и поддержки.

Автоматизация: контроль версии БСП в доработках

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

Базовый приём — выполнять ветку кода только начиная с определённой версии библиотеки:

ТекущаяВерсия = ОбновлениеИнформационнойБазыБСП.ВерсияБиблиотеки();
Если ОбщегоНазначенияКлиентСервер.СравнитьВерсии(ТекущаяВерсия, "3.1.9.0") >= 0 Тогда
    // код, который корректен только для БСП 3.1.9 и новее
КонецЕсли;

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

Где такой контроль окупается на практике:

• 🔁 заимствованный из типовой код, который в новой БСП переписали, — старый вариант оставляют только для старых версий;
• 🧩 расширение, которое должно работать на нескольких базах с разными версиями БСП одновременно;
• 🆕 вызов нового метода библиотеки, появившегося лишь с определённого релиза, — под старой версией его не трогаем.

Во всех трёх случаях номер версии из начала статьи становится не справкой, а рабочим параметром кода.

Частые вопросы