1с история данных использовать

История данных в 1С

Нередко возникают ситуации, когда необходимо определить пользователя, от имени которого были выполнены некие изменения в данных в 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С:Предприятия был установлен флаг «Выполнять обработку после записи версии истории данных» либо программно установлен параметр ВыполнитьОбработкуПослеЗаписиВерсии.

Источник

Запуск встроенного в платформу механизма История данных для ленивых

В последних версиях платформы 1С появился замечательный механизм Истории данных. О нем уже много написано к примеру можно посмотреть тут и вот тут.

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

Возникает вопрос: Как запустить механизм Истории данных для справочника,документа.

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

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

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

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

Ещё нужно учитывать, что автоматом изменения не помещаются в таблицы истории, изменения копятся в очереди на добавление, и чтобы они из очереди попали таблицы истории нужно обновлять историю. Для этого была написана доп. обработка. Если у вас есть механизм БСП: Дополнительные отчеты и обработки, то вы можете добавить эту доп обработку и настроить на неё регламентное задание.

Обработка протестирована на платформе 1С:Предприятие 8.3 (8.3.14.1630).

Источник

Тонкости настройки Истории данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

История данных в 1С

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По умолчанию свойство «История данных» установлено в значение «Использовать» у:

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

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

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

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

Источник

Заметки из Зазеркалья

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

Реализовано в версии 8.3.11.2867.

Мы реализовали новый механизм, история данных, который компактно хранит историю изменения прикладных данных пользователями. С помощью готовых интерфейсных решений или с помощью встроенного языка вы можете теперь гибко анализировать изменения данных, сравнивать разные версии и восстанавливать данные в то состояние, которое они имели в выбранной версии.

В каких сценариях нужна работа с историей данных

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

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

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

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

При этом во всех перечисленных сценариях хочется, чтобы эти возможности достигались с минимальными потерями производительности и места на диске.

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

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

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

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

Какие возможности для анализа истории уже существуют в платформе

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

Другой инструмент, который существует довольно давно и есть во всех тиражных решениях, это БСП – библиотека стандартных подсистем. В её составе есть подсистема версионирования объектов. Эта подсистема содержит все перечисленные функции, однако она имеет некоторые практические ограничения.

Во-первых, она является частью библиотеки, поэтому её внедрение в прикладное решение требует участия квалифицированного разработчика. Хорошо, если БСП изначально присутствует в прикладном решении. Но если её там нет, администратор, или, тем более, квалифицированный пользователь, не смогут самостоятельно её внедрить.

Во-вторых, задача ведения истории данных сама по себе является низкоуровневой задачей, и её эффективнее решать в технологическом слое платформы.

Преимущества решения, встроенного в платформу

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

Основные сведения о механизме

Механизм истории данных полностью реализован внутри платформы, не требует какой-либо установки дополнительных программных средств, в любой момент готов к работе, но, по умолчанию, не включён.

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

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

Хранение истории мы реализовали для справочников, документов, задач, бизнес-процессов и регистров сведений. Возможно в будущем мы будем расширять этот список.

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

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

Обработка изменения данных

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

А вот второй этап инициируется разработчиком. Второй этап заключается в том, что при обработке очереди эти данные извлекаются, помещаются в хранилище версий, и становятся доступными для работы с ними.

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

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

Пользовательский интерфейс

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

Список версий по конкретному объекту

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

Она позволяет увидеть список всех изменений (версий) объекта.

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

В этом списке, в колонке Комментарий, вы можете указать произвольный комментарий, который поможет вам в расследовании каких-то ситуаций.

Отбор версий

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

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

Отчёт о данных версии

Вы можете открыть любую версию объекта, чтобы посмотреть её данные.

Данные будут представлены специальным отчётом, в котором подсвечиваются значения, изменённые по отношению к предыдущей версии.

Отчёт о разнице между версиями

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

Результат сравнения версий будет также показан с помощью отчёта. Этот отчёт напоминает тот, который используется в БСП. Добавленные, изменённые и удалённые значения подсвечиваются.

Программный интерфейс

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

Прежде всего, из встроенного языка вы можете включить/настроить ведение истории. Например, вы можете включить ведение истории для двух реквизитов документа Заказ: реквизита Комментарий самого документа, и реквизита Цена его табличной части, которая называется Товары:

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

Например, вас интересуют все версии документа Заказ с номером 0000001, в которых менялось значение реквизита Количество табличной части, которая называется ПозицииЗаказа. Получить их можно следующим образом:

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

Источник