К статье
Практический материал

Администрирование · 12 мин

Регистр сведений «Версии объектов» в 1С: для чего нужен и как с ним работать

Зачем нужен регистр сведений «Версии объектов» в 1С, как включить версионирование, посмотреть и восстановить версию, очистить регистр и оценить влияние на базу.

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

По своей структуре регистр незамысловат: измерения — «Объект» (ссылка на версионируемый объект) и «Номер версии», ресурсы — сериализованные данные объекта, автор изменения, дата, комментарий, тип версии и признак наличия данных. Каждая запись — это «фотография» объекта на момент записи, упакованная в хранилище значения. Именно поэтому регистр при активном использовании может заметно разрастаться.

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

Как устроено хранение версий в регистре

Когда пользователь записывает версионируемый объект, подсистема перехватывает это событие и создаёт запись в регистре. В ней сохраняются: ссылка на объект, порядковый номер версии, дата и время, автор, тип версии (например, «Изменено»), комментарий и сами данные объекта — сериализованный набор реквизитов и табличных частей. Просмотр версии выполняется десериализацией этих данных в отчётную форму сравнения.

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

Как включить версионирование объектов

В типовых конфигурациях настройка находится в разделе администрирования: «Администрирование» → «Общие настройки» → флажок «Версионирование объектов» (в некоторых конфигурациях путь — «НСИ и администрирование» → «Общие настройки»). После включения становится доступна ссылка «Настроить список версионируемых объектов», где для каждого вида документов и справочников выбирается режим: не версионировать, версионировать при записи или при проведении.

Включайте версионирование точечно. Оптимальные кандидаты — документы, ошибка в которых дорого обходится: банковские и кассовые документы, заказы, счета, карточки контрагентов и номенклатуры. Версионировать всё подряд не стоит: высокооборотные документы вроде «Реализация товаров и услуг» в крупной базе быстро раздувают регистр.

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

Как посмотреть и восстановить версию объекта

Если форма объекта доработана под версионирование, в ней появляется команда «История изменений» (обычно в меню «Ещё»). Отчёт показывает список версий с датами и авторами, а при выборе двух версий — построчное сравнение: какие реквизиты и строки табличных частей изменились, что добавлено и удалено. Это удобно при разборе спорных ситуаций: «кто поменял цену в заказе» или «почему у контрагента другой расчётный счёт».

Восстановление выполняется кнопкой «Перейти на версию» (или аналогичной командой) из формы истории. Подсистема записывает объект данными выбранной версии — при этом создаётся новая версия, то есть сам откат тоже фиксируется в истории. Важно: восстановление документа не перепроводит его корректно по всем механизмам учёта — после отката проведённого документа проверьте движения и при необходимости перепроведите документ штатно.

Очистка устаревших версий и контроль размера регистра

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

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

Типичные ошибки
01
Включить версионирование для всех объектов сразу — регистр быстро раздувается, замедляется запись документов и растёт файл базы.
02
Не настроить регламентное задание очистки — устаревшие версии копятся годами, хотя практической ценности уже не имеют.
03
Считать версии заменой резервного копирования — при повреждении базы версии пропадут вместе с ней.
04
Ожидать историю изменений до включения настройки — объекты, изменённые до старта версионирования, в регистре отсутствуют.
05
Восстанавливать версию проведённого документа без анализа связанных документов — получаете расхождения в учёте.

Доработка форм и программная работа с версиями

Команда «История изменений» не появляется в формах автоматически — её нужно добавить. В типовых объектах это уже сделано; для собственных документов и справочников разработчик добавляет в форму объекта вызов обработчика подсистемы (в БСП это переопределяемые процедуры модуля «ВерсионированиеОбъектов» и команда открытия отчёта по истории). Без этой доработки версии в регистре пишутся, но удобного интерфейса просмотра у пользователя нет.

Программно историю можно получить через запрос к регистру сведений «ВерсииОбъектов» с отбором по измерению «Объект», а данные версии — десериализовать из ресурса. Это используют, например, для построения собственных отчётов по аудиту изменений. При выгрузке базы в DT версии переносятся вместе с остальными данными; при свёртке базы или обрезании истории учтите, что версии удалённых объектов становятся «битыми» записями — их тоже стоит чистить.

Когда версионирование не поможет и что использовать вместо

Регистр не заменяет журнал регистрации: журнал фиксирует события (входы, отказы в доступе, удаление объектов), а версии — содержимое. Для расследования инцидентов безопасности используйте журнал регистрации, для ответа на вопрос «что именно поменяли в документе» — версии. Не заменяет регистр и механизмы дат запрета изменения: версия покажет факт изменения задним числом, но не запретит его.

Если требуется юридически значимый аудит изменений или защита от подделки истории, штатного версионирования недостаточно — записи регистра может удалить администратор базы. В таких сценариях применяют отдельные решения аудита с выгрузкой истории во внешнее хранилище. Для большинства же учётных задач связки «журнал регистрации + версии объектов + даты запрета» достаточно.

Чем закрыть задачу контроля изменений

Версии объектов

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

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

Кто и когда выполнял действия, включая удаление и отказы доступа. Ограничение: не хранит содержимое объекта.

Даты запрета изменения

Запрещают редактирование закрытых периодов. Ограничение: не показывают историю, а только блокируют.

Резервное копирование

Восстановление всей базы при сбое. Ограничение: нет точечного отката одного объекта.

Как проверить, что версионирование работает корректно

После настройки выполните контрольный прогон: создайте тестовый документ версионируемого типа, запишите его, измените пару реквизитов, запишите снова и откройте «Историю изменений». Должны отображаться минимум две версии с корректными автором и датой, а сравнение — подсвечивать изменённые поля. Затем проверьте восстановление на первую версию и убедитесь, что в истории появилась новая запись об откате.

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

Контрольные точки

Как проверить результат

История изменений тестового документа
Норма

Версии создаются при каждой записи, автор и дата корректны, сравнение показывает изменённые реквизиты

Тревожный признак

Список версий пуст или версия одна после нескольких записей — проверьте режим версионирования для этого типа

Регламентное задание очистки версий
Норма

Задание активно, выполняется по расписанию без ошибок

Тревожный признак

Задание отключено или завершается ошибкой — версии копятся бесконечно

Размер регистра
Норма

Рост таблицы соответствует интенсивности работы и сроку хранения

Тревожный признак

Резкий рост после включения версионирования всех объектов — сузьте список типов

Итог

Что важно запомнить

Регистр «Версии объектов» хранит снимки изменённых документов и справочников для просмотра истории и отката. Включайте версионирование точечно, сразу настраивайте очистку устаревших версий и помните: это не замена резервного копирования и журнала регистрации, а дополнение к ним.

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

Почему в списке версий пусто, хотя документ много раз изменяли?

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

Можно ли восстановить удалённый документ через версии объектов?

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

Сильно ли версионирование замедляет работу базы?

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

Как удалить старые версии вручную?

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

Переносятся ли версии при обмене данными между базами?

Нет, регистр версий — локальное хранилище конкретной базы; типовые планы обмена его не синхронизируют. Каждая база ведёт собственную историю изменений своих объектов. Если нужна консолидированная история из нескольких баз, её строят отдельной выгрузкой данных регистра во внешнее хранилище.

Чем отличается версионирование в файловой и клиент-серверной базе?

Логика подсистемы одинакова, различия эксплуатационные: в файловой базе регламентное задание очистки работает только при запущенном сеансе с включённым выполнением заданий, а рост регистра напрямую увеличивает файл 1Cv8.1CD. В клиент-серверном варианте задания выполняет сервер 1С, а размер таблицы контролируют средствами СУБД.