При взаимодействии с заказчиками и пользователями программисты нередко сталкиваются с ситуацией, когда клиент называет неверный номер релиза конфигурации. Типичный пример — запрос информации по «УТ 3.1.10.441». Разберем, почему возникает такое недопонимание, как устроена нумерация решений 1С и какими способами можно безошибочно определить как версию самой конфигурации, так и версию встроенной Библиотеки стандартных подсистем (БСП).
Проанализируем природу номера 3.1.10.441. В линейке типовых решений фирмы «1С» для складского и торгового учета в РФ конфигурация «Управление торговлей» имеет совершенно иные номера редакций: историческая 10.3 или современная 11.x (например, 11.5.17, 11.5.20). Релиза УТ с номером 3.1 не существует в природе.
На самом деле номер 3.1.10.441 — это номер релиза самой Библиотеки стандартных подсистем (БСП). Пользователи или системные администраторы нередко открывают служебные регистры либо системную информацию и принимают версию внедренной библиотеки за версию всей программы. Также путаницу усугубляет то, что номер линейки 3.1 совпадает с популярной конфигурацией «1С:Зарплата и управление персоналом» (ЗУП 3.1).
БСП версии 3.1.10.441 входит в состав современных релизов УТ, таких как 11.5.17.194, 11.5.20.104 и более новых версий линейки 11.5.
Если заказчик называет служебный номер БСП вместо номера конфигурации, объясним ему простой пошаговый алгоритм проверки фактического релиза базы данных:
Если перед нами стоит обратная задача — быстро выяснить, какая именно версия БСП внедрена в текущую базу под управлением пользователя с полными правами, используем встроенные инструменты платформы:
ВерсииПодсистем.СтандартныеПодсистемы. В колонке «Версия» будет указан точный номер БСП, зарегистрированный в информационной базе (например, 3.1.10.441).Если доступ к меню функций технического специалиста ограничен настройками интерфейса, посмотрим версию через Универсальный отчет. Для этого формируем отчет по регистру сведений ВерсииПодсистем с отбором по полю Имя подсистемы = "СтандартныеПодсистемы".
При написании собственных внешних отчетов, обработок или модулей расширений часто требуется проверить возможности библиотеки до вызова специфических методов. Для программного определения релиза БСП используем готовую экспортную функцию общего модуля:
ВерсияБСП = СтандартныеПодсистемыСервер.ВерсияБиблиотеки();
Данная функция возвращает строковое значение текущей версии библиотеки, например "3.1.10.441". Если требуется проверить совместимость функционала, можно выполнить сравнение версий с помощью служебной функции ОбщегоНазначенияКлиентСервер.СравнитьВерсии().
Когда информационная база недоступна для запуска в режиме предприятия, но есть доступ к конфигуратору или файлу конфигурации (cf), выясним версию через код конфигурации:
ОбновлениеИнформационнойБазыБСП.ПриДобавленииПодсистемы(Описание).Описание.Версия:
Процедура ПриДобавленииПодсистемы(Описание) Экспорт
Описание.Имя = "СтандартныеПодсистемы";
Описание.Версия = "3.1.10.441";
КонецПроцедуры
Значение в этой процедуре жестко фиксирует версию поставляемой в составе конфигурации библиотеки.
Обратим внимание на техническую деталь: значение, возвращаемое методом СтандартныеПодсистемыСервер.ВерсияБиблиотеки() из метаданных, и значение в регистре сведений ВерсииПодсистем могут не совпадать. Проанализируем, почему это происходит:
ВерсииПодсистем хранится версия, до которой база была фактически обновлена на уровне данных. Данная запись обновляется только после успешного завершения всех процедур обновления информационной базы.Если после обновления конфигурации произошел сбой, информационная база не запускалась в режиме предприятия или аварийно завершились фоновые задания отложенного обновления, запись в регистре останется старой. Всегда сопоставляем значение в регистре и в метаданных, чтобы убедиться в корректности обновления информационной базы.