Администрирование · 11 мин
Версионирование в 1С: где хранятся версии объектов
Где хранятся версии объектов в 1С, как включить версионирование, очистку истории и восстановление данных. Разбор хранилища, регистров и типичных ошибок.
Версионирование объектов в 1С — это механизм, который автоматически сохраняет историю изменений справочников и документов: кто, когда и что именно поменял. Когда пользователь спрашивает «где хранится версионирование в 1С», обычно речь идёт о двух вещах: где физически лежат сохранённые версии в базе данных и где в интерфейсе посмотреть историю изменений конкретного объекта.
Механизм реализован в подсистеме «Версионирование объектов» Библиотеки стандартных подсистем (БСП), которая входит в состав большинства типовых конфигураций: «1С:Бухгалтерия», «1С:Управление торговлей», «1С:ERP», «1С:Зарплата и управление персоналом» и других. Сохранённые версии хранятся не в отдельных файлах, а внутри самой информационной базы — в специальном регистре сведений. Это важно понимать, потому что рост истории напрямую увеличивает размер базы.
Ниже разберём, где именно физически хранятся версии, как включить механизм, как посмотреть и восстановить старую версию, как ограничить разрастание истории и какие ошибки встречаются чаще всего.
Где физически хранятся версии объектов
Все сохранённые версии записываются в регистр сведений «Версии объектов» (ВерсииОбъектов). Это служебный регистр подсистемы БСП, и в файловой базе его данные физически находятся внутри файла 1Cv8.1CD, а в клиент-серверном варианте — в таблицах базы данных на СУБД (MS SQL Server, PostgreSQL и др.). Отдельных файлов с историей на диске не создаётся.
Само содержимое версии хранится в виде сериализованного объекта: данные объекта преобразуются в XML-представление, которое упаковывается (сжимается) и помещается в хранилище значения регистра. Поэтому открыть версию «блокнотом» или прочитать её напрямую из таблицы SQL нельзя — для просмотра используется штатный механизм платформы, который распаковывает и десериализует данные.
Вместе с содержимым в регистре фиксируются служебные реквизиты: ссылка на объект, номер версии, дата и время записи, автор изменения, тип версии (изменение данных, пометка удаления и т. п.), а также комментарий, если пользователь его указал. По этим полям строится журнал истории изменений.
Где в интерфейсе посмотреть историю изменений
Для конечного пользователя история доступна прямо из карточки объекта. Откройте нужный документ или элемент справочника и выполните команду «Ещё» → «История изменений» (в некоторых конфигурациях — кнопка «История изменений» на панели команд). Откроется таблица версий с датами, авторами и номерами версий.
Из журнала можно открыть любую версию в режиме просмотра, сравнить две версии между собой — система покажет отличия по реквизитам и табличным частям — и восстановить объект до выбранного состояния. Сравнение особенно полезно, когда нужно понять, какое именно поле было исправлено: изменённые значения подсвечиваются.
Если команда «История изменений» отсутствует, причины обычно две: версионирование для этого вида объектов не включено в настройках, либо у пользователя нет прав на просмотр версий. Проверку начинайте с настроек подсистемы.
- 1Откройте документ или элемент справочника
- 2Нажмите «Ещё» → «История изменений»
- 3Выберите версию и откройте её для просмотра
- 4Для сравнения выделите две версии и нажмите «Сравнить»
- 5При необходимости восстановите объект из нужной версии
Как включить и настроить версионирование
Настройка выполняется в разделе «Администрирование» → «Общие настройки» (в некоторых конфигурациях — «Настройки работы с файлами и версионирование» или «Поддержка и обслуживание»). Нужно установить флажок «Версионирование объектов» и для каждого вида объектов выбрать режим: не версионировать, версионировать при записи или версионировать при проведении.
Режим «версионировать при проведении» применяется к документам: версия сохраняется только при проведении, а промежуточные записи не фиксируются. Это разумный компромисс для документооборота с высокой интенсивностью. Для справочников обычно используют «версионировать при записи», так как изменения нормативно-справочной информации случаются реже, но каждое из них может быть критичным.
Дополнительно можно включить обязательный комментарий при изменении — тогда система потребует от пользователя пояснить причину правки. Это дисциплинирует сотрудников, но замедляет работу, поэтому включайте опцию осознанно, в первую очередь для критичных справочников: договоров, банковских счетов, номенклатуры.
Как восстановить объект из версии
Восстановление выполняется из журнала истории: выделите нужную версию и нажмите «Восстановить». Система запишет объект данными из выбранной версии, при этом само восстановление тоже зафиксируется как новая версия — история не перезаписывается, а пополняется. Это защищает от потери информации даже при ошибочном откате.
Есть важное ограничение: восстановление документа возвращает его данные, но не отменяет автоматически движения по регистрам в прошлом состоянии — документ будет перепроведён в текущем контексте. Если за прошедшее время изменились цены, остатки или настройки учёта, результат проведения восстановленного документа может отличаться от того, что было раньше. После восстановления проверьте движения документа и связанные отчёты.
Для помеченных на удаление объектов история также доступна: можно найти помеченный объект, открыть историю и восстановить версию до пометки. Это один из практических способов спасти случайно «удалённые» данные без обращения к резервной копии.
Очистка истории и контроль размера базы
Регистр «Версии объектов» растёт постоянно: каждая запись документа или справочника добавляет сжатую XML-копию объекта. В базах с интенсивным документооборотом регистр со временем может занять заметную долю объёма базы, что влияет на скорость резервного копирования и обновления.
В типовых конфигурациях есть штатная регламентная операция «Очистка устаревших версий объектов» (раздел «Администрирование» → «Поддержка и обслуживание» → «Регламентные операции»). Она удаляет версии старше заданного срока хранения. Срок хранения настраивается индивидуально для каждого вида объектов — например, для документов 6 месяцев, для ключевых справочников — бессрочно.
Если регистр уже разросся, разовую очистку можно запустить вручную из того же раздела. На клиент-серверных базах большого объёма очистку лучше выполнять в нерабочее время: удаление миллионов записей создаёт нагрузку на СУБД и может блокировать таблицы.
Как проверить результат
Команда «История изменений» доступна, версии открываются и сравниваются
Команды нет или список версий пуст при включённом механизме
Рост регистра соответствует интенсивности работы, очистка выполняется по расписанию
Регистр растёт неконтролируемо, регламентная очистка не настроена
Объект восстанавливается, создаётся новая версия с записью об откате
Ошибки при восстановлении, объект не перепроводится
Ограничения механизма и альтернативы
Штатное версионирование БСП охватывает не все объекты: по умолчанию поддерживаются справочники и документы, а регистры сведений, планы счетов и некоторые другие типы версионируются только при наличии доработок. Также механизм не заменяет резервное копирование — он хранит историю объектов, но не защищает от физической порчи базы.
Если требуется контроль версий самой конфигурации (а не данных), используется другой инструмент — хранилище конфигурации. Оно создаётся через Конфигуратор («Конфигурация» → «Хранилище конфигурации») и хранит версии модулей, форм и метаданных. Файл хранилища (обычно 1Cv8ddb.1CD или каталог хранилища) размещается в сетевой папке, доступной разработчикам, — это единственный случай, когда «версии» в 1С действительно лежат в отдельном файле на диске.
Что где хранится
Внутри информационной базы, регистр сведений «Версии объектов». Для истории изменений документов и справочников.
Отдельный файл/каталог в сетевой папке. Для версионирования кода и метаданных при разработке.
Внешние файлы выгрузки (.dt) или копии СУБД. Для защиты от потери базы целиком, историю не заменяют.
Типичные ошибки при работе с версионированием
Отдельная частая ситуация — попытка найти версии средствами СУБД или текстовым поиском по файлу базы. Так как данные сжаты и сериализованы, прямой доступ к ним бесполезен и опасен: ручные правки таблиц регистра нарушают целостность базы. Любые операции с версиями выполняйте только штатными средствами платформы.
Что важно запомнить
Версии объектов хранятся внутри базы в регистре сведений «Версии объектов» в сжатом XML-виде; отдельных файлов нет. Включается механизм в «Администрирование» → «Общие настройки», история смотрится из карточки объекта, а размер регистра контролируется регламентной очисткой. Версии конфигурации — это отдельное хранилище в сетевой папке, не путайте механизмы.
Частые вопросы
Можно ли посмотреть версии объектов за период до включения механизма?
Нет. Версионирование фиксирует изменения только с момента активации. Единственный способ увидеть прошлое состояние данных — развернуть архивную копию базы за нужную дату.
Занимает ли версионирование много места в базе?
Каждая версия — это сжатая XML-копия объекта, поэтому при умеренной интенсивности работы рост незначителен. Проблемы возникают при массовых перепроведениях без настроенной очистки: тогда регистр может стать одной из крупнейших таблиц базы.
Кто может просматривать историю изменений?
Пользователи с соответствующими правами — в типовых конфигурациях обычно это роль просмотра истории версий, входящая в профили администраторов и часть пользовательских профилей. Если команда «История изменений» недоступна, проверьте права в разделе администрирования пользователей.
Восстановит ли версия документа его движения по регистрам?
Восстановление возвращает данные документа, после чего он перепроводится в текущем контексте учёта. Если с момента исходного проведения изменились цены, остатки или настройки, движения могут отличаться от первоначальных — результат нужно проверить по отчётам.
Чем версионирование объектов отличается от хранилища конфигурации?
Версионирование объектов сохраняет историю данных (документов, справочников) и хранится внутри базы. Хранилище конфигурации — инструмент разработчиков, оно хранит версии кода и метаданных в отдельном файле в сетевой папке. Это независимые механизмы.
Можно ли перенести историю версий в другую базу?
Штатного механизма переноса истории между базами нет: регистр «Версии объектов» служебный, и типовые обмены его не переносят. При переходе на новую базу история остаётся в старой, поэтому архивную базу обычно сохраняют для справок.