Как в конфигурации 1С найти историю установленных обновлений с датами?

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

Рассмотрим подробно все доступные инструменты и методы, которые помогут нам получить информацию об истории обновлений.

Использование регистров Библиотеки стандартных подсистем (БСП)

В современных типовых конфигурациях (таких как Бухгалтерия предприятия 3.0, Управление торговлей 11, ERP) учет версий ведется программно через механизмы БСП. Это наиболее удобный способ для пользователя и администратора, так как данные хранятся непосредственно в базе данных.

Разберем основные регистры, которые нам помогут:

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

Анализ Журнала регистрации

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

Для поиска истории обновлений в Журнале регистрации выполним следующие шаги:

1. Установим фильтр по колонке «Событие».
2. Выберем события: «Конфигурация. Изменение конфигурации базы данных» и «Конфигурация. Обновление конфигурации».
3. Проанализируем результаты: событие «Обновление конфигурации» фиксирует факт загрузки файла обновления (.cfu или .cf), а «Изменение конфигурации базы данных» — момент фактического применения новой структуры данных (нажатие F7 в конфигураторе).

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

Работа с Хранилищем конфигурации

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

Рассмотрим нюансы этого метода:

• В истории хранилища фиксируется дата помещения изменений в хранилище.
• Важно понимать, что дата помещения в хранилище не равна дате применения обновления на рабочей (боевой) базе.
• Однако, история хранилища позволяет увидеть комментарии разработчиков и номера релизов, которые готовились к выпуску.

Программные методы получения текущей версии

Иногда программисту требуется программно определить, какая версия конфигурации сейчас запущена, чтобы логика программы адаптировалась под актуальный релиз. Для этого используем встроенный язык.

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

ВерсияКонфигурации = Метаданные.Версия;
Сообщить("Текущая версия конфигурации: " + ВерсияКонфигурации);

// Если используется БСП, можно получить версию через менеджер обновлений
ТекущаяВерсияБСП = СтандартныеПодсистемыСервер.ВерсияПодсистемы("СтандартныеПодсистемы");

Проанализируем ситуацию, когда нам нужно отследить момент изменения метаданных. Для этого можно использовать справочник «Идентификаторы объектов метаданных». Записи в этом справочнике создаются или обновляются при каждом изменении состава объектов в системе. Дата создания записи о новом справочнике или документе может служить маркером даты установки обновления, принесшего эти изменения. Для быстрого поиска методов и процедур библиотечных подсистем пригодится справочник по методам БСП с примерами использования.

Низкоуровневый анализ (SQL-уровень)

Для системных администраторов и специалистов, работающих с клиент-серверным вариантом, существует возможность заглянуть «под капот» на уровне СУБД (MS SQL, PostgreSQL). Информация о конфигурации хранится в системных таблицах базы данных.

Выясним, где именно искать данные: В таблице Config хранятся записи с именами root, versions и confinfo. По дате последнего изменения этих записей (столбец modified или аналогичный в зависимости от СУБД) можно определить время последней реструктуризации базы данных. Это наиболее точный технический способ узнать время применения обновления на уровне таблиц SQL.

Резюме

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