Обновить историю данных 1с

Обновлено: 05.07.2024

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

1. Что такое история данных в 1С

В этом случае может помочь механизм платформы 1С, называемый историей (или версионированием в 1С) данных.

История данных – механизм платформы 1С, позволяющий хранить историю изменения данных пользователями, упорядоченную по времени. При этом в базе данных хранится не полная копия объекта до и после изменения, а только «разница». Также при настройке можно указать, что версионирование в 1С требуется не для всех объектов, а только для интересующих.

Данные возможности положительно сказываются на производительности и позволяют производить экономию дискового пространства.

2. Для каких видов объектов метаданных 1С реализована история хранения данных

Хранение истории реализовано для следующих видов объектов метаданных 1С:

- планы видов расчетов

Начиная с версии платформы 8.3.13.1513 в список видов объектов с поддержкой истории данных добавлены:

- планы видов характеристик

По умолчанию для большинства объектов отключено ведение истории данных в 1С, разработчик сам решает, в каких случаях требуется установить использование механизма.

3. Как включить механизм версионирования в 1С

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

При настройке 1С:Предприятия можно выбрать полный режим хранения объекта или частичный (хранение изменений значений отдельных реквизитов, измерений, также могут быть сохранены изменения значений реквизитов табл. частей).

Программная работа с историей данных осуществляется через свойство глобального контекста ИсторияДанных типа МенеджерИсторииДанных. Предлагаемые методы позволяют производить запись версий, получать различия версий, выполнять поиск версий в соответствии с отбором, дополнять версию комментарием, удалять версии.

Рассмотрим, как выполняется запись версии.

Запись версии может быть выполнена 2 способами:

- автоматически механизмами платформы 1С (основной вариант использования)

- обработкой на встроенном языке методом ЗаписатьВерсию().

Автоматическое формирование истории данных выполняется в несколько этапов:

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

Стоит отметить, что свойство «Обновлять историю данных сразу после записи» не рекомендуется устанавливать для видов объектов метаданных 1С, для которых предполагается большое количество элементов и частое их изменение.

2. Фактическая запись версии в базу.

3. Постобработка после записи в историю данных.

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

Данная команда выполняется только с правами Администратор.

Если необходимо для конкретного объекта создать версию данных принудительно, то необходимо выполнить после записи объекта код:

Так как же это все таки работает.

Все версии данных, при сохранении объектов попадают в очередь (таблица dbo._DataHistoryQueue0 на сервере SQL), и накапливаются там, пока не выполнится команда

Далее записи перемещаются в dbo._DataHistoryVersions, собственно из этой таблицы мы и видим данные, когда заходим в клиенте в раздел «История изменений»

Вроде бы ничего сложного, можно пользоваться.

Оказывается, есть нюансы:

А) Необходимо вести историю данных, причем сохранять изменения, которые делали пользователи, а не регламентные задания.

Б) Так же необходимо учесть, если объект пересоздается в другом месте БД, необходимо перенести и его историю. Например: оборудование демонтировали. В БД есть два объекта 1) Оборудование подразделения и 2) Демонтированное оборудование подразделения. При демонтаже в первом объекте запись удаляется, а во-втором создается путем копирования части реквизитов (структуры объектов не одинаковые).

Решение:Для решения пункта А) нам необходимо в объектах использовать процедуру

, где Ссылка на объект – ссылка на объект, для которого необходимо записать версию, т.е. объект, которые мы только что записали.

Почему после записи?

Потому что версия формируется не из формы, а из сохраненной записи БД.

Почему не используется

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

все эти версии будут привязаны к объекту.

Для решения Б) нам придется немного схитрить. Дело в том, что готовой функции переноса истории с объекта в объект нет. Так что будем переписывать историю

После записи во-второй объект («Демонтированное оборудование подразделения»), нам необходимо его получить и добавить историю, которая была у объекта Источника:

, где Ссылка на объект – ссылка на объект источника, историю которого мы хотим передать новому объекту.

После переноса истории данных, во-втором объекте будут видны только те поля истории, которые совпадают по наименованию и типу с первым объектом.

Поля, которые нужны только для отображения истории первого объекта, и не используются во-втором объекте можно скрыть от пользователей и не заполнять при переносе из первого объекта.

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

К сожалению, во встроенной функции ИсторияДанных такой команды нет, поэтому пришлось делать костыльное решение. В SQL создал плановое задание из двух шагов:

Первый шаг, чистить таблицу очереди истории данных

Второй шаг, сжимает БД.

Если второй шаг не выполнять, БД не уменьшится в размерах.

В итоге размер БД сократился в 20 раз. Именно столько накопилось в очереди за 2 месяца использования истории данных.

Специальные предложения

Боже мой, что же у Вас всё так сумбурно написано :-( Вот так и не смог понять - ради чего это всё тут написано - что за такие сложности при работе с историей?

Я, просто, не использую типовой механизм, у меня очень давно используется самописное универсальное решение - и я просто не могу понять - откуда проблемы?
У самописки - было только два "тонких места" - это работа в РИБ (особенно когда возникло желание существенно "упаковать" данные истории - чтобы не использовать ссылки UID по 32 байта и не дублировать одинаковые строки); и вынос истории в отдельную базу (ибо хранить её - в той же базе - это бред "сивой кобылы", такой же, нет, ещё больший, как и бред хранить в той же базе присоединённые файлы - когда они есть почти у всех первичных документов в виде куче сканов).

А у Вас тут прям какие-то совершенно непонятные проблемы!

Ну ясен пень - что необходимость вызывать "ИсторияДанных.ОбновитьИсторию()" в основном это бред - историю придётся писать вручную, по старинке, через подписки на события через "ИсторияДанных.ЗаписатьВерсию(. )" - ибо, если кто-то сейчас пишет историю, то наверняка кто-то может её сейчас или через 5 минут уже анализировать (часто бывает - записываешь - и сразу смотришь - что там изменилось).
А переходить на отложенное выполонение через "ИсторияДанных.ОбновитьИсторию()" имеет смысл только выборочно - при массовых изменениях данных в обработках.

А вот, про перенос истории мне вообще не ясно - ЗАЧЕМ?

Как и про чистку таблицы "dbo._DataHistoryQueue0", она что - сама при вызове указанных выше функций записи истории не очищается?

За свою практику работы 1C программистом я видел два варианта хранения истории изменения данных: в основной базе регистр сведений с полем типа хранилище значений, заполняется по подписке на событие записи и в отдельной базе, доступ к которой происходит по OLE. Стандартное решение - БСП, подсистема "Версионирование объектов". Возможность хранения истории данных очень полезна, когда нужно найти причину ошибки в данных или просто найти ~~крайнего~~ ответственного. И вот наконец такую возможность включили в платформу, по информации сайта Заметки из Зазеркалья.

Конечно, платформа версии 8.3.11 еще пока находится в тестировании , в типовых конфигурациях это решение появится еще не скоро, но любопытство побеждает.

Посмотрим, что за механизм такой. Устанавливаем на компьютер платформу версии 8.3.11. 2831 Для тестирования подойдет В синтакс-помощнике появился менеджер истории данных, видно его методы.

История данных поддерживается для объектов: общие реквизиты, справочники, документы, бизнес-процессы, задачи, регистры сведений. В свойствах полей появилась настройка "История данных" (внизу рисунка).

Для некоторых стандартных реквизитов настройка пока не появилась (например, Пометка удаления). Возможно, это ~~глюк~~ особенность тестовой версии. Для простоты будем считать, что в конфигураторе новой версии у всех объектов (документы, справочники) установлено История данных = НеИспользовать, у реквизитов История данных = Использовать. Для табличных частей это свойство не имеет смысла, поскольку задается отдельно для каждого реквизита табличной части.

Откроем обработку " НастройкаХраненияДанных ", которая позволяет изменять настройки в режиме предприятие и находить отличия.

Кнопка "Заполнить метаданные" выводит дерево метаданных по конфигурации. Пока настройки предприятия не заданы, колонка "История данных" показывает настройки из конфигуратора. Содержимое колонки можно изменять.
Кнопка "Установить настройки" применяет одноименный метод к каждому объекту метаданных из дерева.
Кнопка "Обновить историю" записывает изменения данных из временного хранения на постоянное. В документации рекомендуют метод ИсторияДанных.ОбновитьИсторию() вызывать раз в сутки, регламентным заданием, желательно НЕ в транзакции.

После установки свойства "История данных" документа "Приходная накладная" изменения начинаются фиксироваться. Создаем документ "Приходная накладная" № 3, сохраняем, затем изменяем реквизит Сумма по документу: вместо 3 пишем 0, сохраняем.

Переходим в обработку "Восстановить данные", в качестве текущего объекта выбираем документ "Приходная накладная" № 3.

Метод "ВыбратьВерсии" пока не показывает ни одной версии. Нажимаем "Обновить историю" из первой обработки. Теперь метод "ВыбратьВерсии" возвращает нам таблицу значений. Две версии - две строки. Вид изменения имеет два значения по версиям: сначала мы создали документ, потом изменили. В таблице значений несколько колонок скрыты.

Вывод: механизм интересный, заявленные функции выполняет. Примеры кода, обработки внутри прикрепленого файла.

Общая информация

Начнем с общей теоретической информации о том, что такое история данных и как она устроена.

Описание и возможности

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

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

Само по себе хранение истории достаточно бесполезная функция, поэтому с историей данных можно выполнять следующие операции:

записывать версию данных;
получать данные определенной версии;
удалять данные определенной версии;
получать разницу между двумя версиями одного объекта;
прочие полезные возможности.

На момент написания статьи (8.3.13) история данных поддерживается для следующих объектов:

общие реквизиты;
константы;
справочники;
документы;
бизнес-процессы;
задачи;
регистры сведений;
планы обмена;
планы счетов;
планы видов характеристик;
планы видов расчетов;
расширения конфигурации.

Работа с историей данных регулируется правами доступа и отражается в журнале регистрации.

Устройство механизма

История данных хранится в специальных таблицах информационной базы. Кроме самих данных в этих таблицах хранятся метаданные прежних версий объектов. Версии метаданных создаются в момент изменения этих самых метаданных у объекта и никак не связаны с изменением данных объекта.

Также следует помнить, что на данный момент система не отличает включение версионирования для реквизита от создания реквизита и отключение версионирования реквизита от удаления реквизита.

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

стандартных реквизитов;
реквизитов объектов;
реквизитов табличных частей;
измерений регистров сведений (без возможности отключения);
ресурсов регистров сведений.

Использование механизма

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

Управление использованием истории данных

Читайте также: