Что такое история реквизита как ее посмотреть

Когда с базой 1С работают несколько сотрудников, возникают вопросы:

• как отследить действия пользователей в системе;
• как посмотреть в 1С кто изменял документ;
• где увидеть историю изменения документа;
• как вернуть данные к прежнему виду?

Найти ответы помогут Журнал регистрации и История изменений.

Работу с Журналом регистрации и Историей изменений рассмотрим на примере конфигурации 1С Бухгалтерия 8.3.

Журнал регистрации и История изменений

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

Журнал регистрации больше ориентирован на фиксирование действий с программой в целом — таких, как изменение параметров, настроек. А механизм Истории изменений — на хранение предшествующих версий документов и справочников. Он появился в типовых конфигурациях с версии 8.3.11, а с 8.3.13.1513 к списку объектов добавились константы, планы обмена и планы видов характеристик. Журнал регистрации начинает собирать информацию автоматически с момента установки программы, а для начала работы Истории изменений требуется ее включение и настройка.

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

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

• ошибки — любые сбои в системе;
• предупреждения — системные сообщения;
• информация — действия с данными;
• примечания — малозначимые оповещения.

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

Подробнее Журнал регистрации в 1С 8.3

Где найти журнал регистрации

Журнал регистрации, в котором хранится история изменений в 1С 8.3, можно найти в разделе: Администрирование — Обслуживание — Журнал регистрации.

Настройка журнала

Для сокращения количества записей и точной настройки задайте параметры:

• Показывать — количество записей в окне журнала;
• Критичность— выберите:
  • Все события — без отбора по событиям;
  • Ошибка — возникшие в программе ошибки;
  • Предупреждение — выведенные на экран предупреждения для пользователей;
• Интервал — задайте, если нужен список записей в журнале регистрации за период, отличный от указанного в поле Отбор (по умолчанию там указана текущая дата).

Кнопка Установить отбор — это расширенный отбор для получения данных по конкретному событию или объекту. Чтобы отобразить сведения по документу, настройте:

• Интервал — период, за который сформируются записи о действиях с документом. Если период неизвестен, устанавливается максимальный: с даты создания документа по текущее число;
• Метаданные — укажите для получения информации по всем документам одного вида;
• Данные — укажите конкретный документ. Для этого выберите в поле из списка наименование документа.

После нажатия кнопки ОК откроется журнал документов. По дате и номеру найдите тот, по которому требуется просмотреть зарегистрированные действия. Период, указанный в окне отбора журнала регистрации, не влияет на сформированный журнал со списком документов.

Кнопка Применить и закрыть — завершение настройки расширенного отбора.

Сформируется отчет по зафиксированным событиям по документу за указанный период. Для открытия измененного объекта выберите из контекстного меню пункт Открыть данные для просмотра.

Как читать журнал

В журнале регистрации выводятся графы:

• Дата, время — дата и время события;
• Пользователь, компьютер, приложение, сеанс — имя пользователя, имя компьютера, с которого запущена программа, режим запущенного приложения (стандартно для всех пользователей, работающих с базой данных 1С — Тонкий клиент);
• Событие, данные и метаданные, комментарий:
  • событие — произошло с Добавление информации (возможны: Изменение, Проведение);
  • данные — событие связанно с Данными (возможны: Доступ, Пользователи, Сеанс, Фоновое задание);
  • метаданные — объект, с которым произошло событие: Счет покупателю 0000-000001 от 26.10.2020 16:50:31, относится к типу Документ, вид Счет покупателю;
  • комментарий программа указывает в случае возникновения ошибки или предупреждения.

История изменений документа в 1С 8.3 (или справочника) хранит все версии объекта — от создания до последнего редактирования и проведения. Механизм позволяет:

• отследить изменения, сделанные пользователем;
• увидеть предыдущие данные;
• сопоставить измененную информацию со старой;
• вернуть документ/справочник к изначальному виду.

Включение и настройка

Расположение функции в программе:

• зайдите в систему под пользователем с правами администратора;
• меню Администрирование – Общие настройки;
• откройте раздел История изменений и установите флаг Хранить историю изменений.

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

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

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

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

• Никогда — не хранить данные об изменениях;
• При записи:
  • для документов — собирать историю редактирования не проведенных документов;
  • для справочников — сохраняются все изменения;
• При проведении (для документов) — фиксировать изменения в проведенных документах;
• По умолчанию предлагает настройки:
  • для справочников — Никогда;
  • для документов — При проведении (для документов).

Установить срок хранения версий — определяется время хранения версий:

• За последнюю неделю;
• За последний месяц;
• За последние три месяца;
• За последние шесть месяцев;
• За последний год;
• Бессрочно — хранить историю всегда.

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

Просмотр истории изменений документа или справочника

Как в 1С посмотреть историю изменения документа/справочника после включения опции:

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

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

• Откроется окно История изменений с отчетом о редактировании документа/справочника. Включает дату изменения и имя пользователя, сделавшего корректировки.

Жирным цветом выделена текущая версия. Для просмотра деталей нажмите кнопку Открыть версию. Версия документа/справочника на выбранную дату отображается в виде отчета со значениями реквизитов.

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

Сравнение версий документа/справочника:

• Откройте окно История изменений.
• Выделите строки с зажатой клавишей Shift или Ctrl и нажмите кнопку Сравнить. Сформируется отчет по изменениям, где каждой выбранной позиции отведена колонка. Порядок столбцов по умолчанию: в последней колонке отражены начальные данные (из выбранных версий), а в первой — конечные изменения (среди выбранных для сравнения). Сопоставлять можно любое количество версий.

Измененное значение реквизита подсвечивается.

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

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

Таким образом, посмотреть в 1С кто корректировал данные можно несколькими способами. Журнал регистрации и История изменений заложены во все типовые решения фирмы 1С. У каждого из них есть преимущества и недостатки. В Журнале регистрации предусмотрен расширенный механизм отбора информации по всей базе данных, а история изменений привязана и открывается по конкретному документу или справочнику. На практике для получения эффективных результатов при поиске измененных данных используют оба способа совместно.

См. также:

• Журнал регистрации в 1С 8.3
• Поиск и удаление дублей
• Загрузка данных из табличного документа 1С 8.3
• Как выгрузить документ, отчет из 1С 8.3 в Excel
• Сбилась нумерация документов в 1С 8.3: как исправить
• Как удалить помеченные на удаление документы
• Поиск и замена значений 1С 8.3
• Исправление технических ошибок при работе с 1С:Бухгалтерия

Если Вы еще не подписаны:

Активировать демо-доступ бесплатно →

или

Оформить подписку на Рубрикатор →

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

Подписывайтесь на наши YouTube и Telegram чтобы не пропустить
важные изменения 1С и законодательства

Помогла статья?

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно

26.05.2017

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Чтобы воспользоваться этим механизмом администратору или пользователю не придётся изменять конфигурацию, всё необходимое уже есть в платформе. Нужно только включить.
• Этот механизм будет работать быстрее, чем аналоги, реализованные в составе конфигурации, т.к. он будет использовать возможности, недоступные из встроенного языка.
• Сама история данных будет занимать меньше места, так как будет храниться не копия данных, а только их разница с предыдущей версией. Кроме этого само версионирование можно применять не ко всем реквизитам, а только к тем, которые интересуют. Это также даст дополнительную экономию.
• Можно будет поддержать версионирование не только тех объектов, которые обладают уникальной ссылкой (справочники, документы и т.п.), но и необъектных сущностей, таких как записи регистров сведений, например.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отбор версий

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

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

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

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

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

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

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

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

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

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

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

Настройки = Новый НастройкиИсторииДанных; Настройки.Использование = Истина; Настройки.ИспользованиеПолей.Вставить(«Комментарий», Истина); Настройки.ИспользованиеПолей.Вставить(«Товары.Цена», Истина); ИсторияДанных.УстановитьНастройки(Метаданные.Документы.Заказ, Настройки);

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

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

Отбор = Новый Структура(«Данные, ИзменениеЗначенийПолей»); Отбор.Данные = Документы.Заказ.НайтиПоНомеру(«0000001»); Отбор.ИзменениеЗначенийПолей = Новый Массив; Отбор.ИзменениеЗначенийПолей.Вставить(«ПозицииЗаказа.Количество»); Версии = ИсторияДанных.ВыбратьВерсии(Отбор, «НомерВерсии, Дата, ТипИзменения, ИмяПользователя, Комментарий»);

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

Теги:
история данных 
8.3.11 

Ключевые слова: Регистрация, история, изменение.

Эта статья является описанием озвученного в Книга знаний: v8: Регистрация событий третьего алгоритма.

Речь о том, чтобы хранить в базе историю изменения реквизитов объектов.

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

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

Общая идею проста, как четыре рубля одной монетой.

А вот при ближайшем рассмотрении выяснилось пара нюансов.

А при превращении мыслей в статью и вовсе все поменялось.

Начнем по-порядку.

Для начала, делаем периодический регистр сведений «История реквизитов» без привязки к регистратору.

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

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

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

А с другой стороны и без этого реквизита совсем уж никуда, ни отчета сформировать, ни просто даже объект найти.

Поэтому, в каждый объект, для которого требуется регистрация изменений реквизитов, добавляем реквизит «GUID» типа «Строка (32)».

Кроме того, в регистр сведений «История реквизитов» добавляем измерение «GUID объекта» типа «Строка (32)».

Так я хотел написать сначала.

А потом хорошо подумал.

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

Во-вторых, журнал регистрации фирмой 1С реализован таким образом, что в нем в реквизите «Данные» хранится именно ссылка на объект, а никакой не GUID.

Просто при удалении объектов журнал регистрации не участвует в проверке ссылочной целостности и после удаления объекта в нем в реквизите «Данные» показывается знакомая многим надпись «<Объект не найден> …».

В-третьих, GUID вместо ссылок придется тогда вставлять и в остальных полях, то есть в пользователе, старом значении и новом значении.

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

Тем паче, что типовой алгоритм крайне скуден.

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

Почему пустыми?

Да все просто, чтобы ссылочная целостность базы не нарушалась.

Поэтому добавляем измерение «Объект» типа «Любая ссылка».

Вместо типа «Любая ссылка» можно проставить галочки у конкретных объектов, без разницы.

Продолжаем.

Помимо объекта нужно иметь информацию о реквизите, который меняется.

Поэтому добавляем измерение «Реквизит» типа «Строка (25)» или «Справочник.РеквизитыОбъектов», кому как больше нравится.

Я для примера сделал строкой.

Затем добавляем информацию о пользователе, сделавшем изменения.

Для этого добавляем ресурс «Пользователь» типа «Справочник.Пользователи».

Кроме того, добавляем ресурс «Имя компьютера» типа «Строка (25)».

Кому 25 символов мало, может изменить на нужное количество.

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

И, наконец, добаляем два ресурса, «СтароеЗначение» и «НовоеЗначение» составного типа.

В составе типов «Число», «Строка», «Булево», «Дата» и «Любая ссылка».

Размерность типов «Число» и «Строка» проставляется максимальная из возможных, чтобы в нее уместилось содержимое любого реквизита.

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

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

Теперь по поводу настроек в объектах.

Во всех объектах, для которых будет регистрироваться история, требуется прописать следующий код.

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

Перем НаборЗаписейИсторияОбъектов;

Процедура ПередЗаписью(Отказ)
    
    НаборЗаписейИсторияОбъектов = РегистрыСведений.ИсторияОбъектов.СоздатьНаборЗаписей();
    
    ОбработатьИзменениеРеквизита(НаборЗаписейИсторияОбъектов, "Код");
    ОбработатьИзменениеРеквизита(НаборЗаписейИсторияОбъектов, "Наименование");
    ОбработатьИзменениеРеквизита(НаборЗаписейИсторияОбъектов, "Родитель");
    ОбработатьИзменениеРеквизита(НаборЗаписейИсторияОбъектов, "Владелец");
    
    Для А = 0 По ЭтотОбъект.Метаданные().Реквизиты.Количество() - 1 Цикл
        ОбработатьИзменениеРеквизита(НаборЗаписейИсторияОбъектов, ЭтотОбъект.Метаданные().Реквизиты[А].Имя);
    КонецЦикла;
    
КонецПроцедуры

Процедура ПриЗаписи(Отказ)
    
    Если НаборЗаписейИсторияОбъектов.Количество() <> 0 Тогда
        
        Для Каждого Запись Из НаборЗаписейИсторияОбъектов Цикл
            Запись.Объект = Ссылка;
        КонецЦикла;
        
        НаборЗаписейИсторияОбъектов.Записать(Ложь);
        
    КонецЕсли;
    
КонецПроцедуры

Процедура ОбработатьИзменениеРеквизита(НаборЗаписейИсторияОбъектов, ИмяРеквизита)
    
    Если ЭтотОбъект[ИмяРеквизита] <> Ссылка[ИмяРеквизита] Тогда
        
        НоваяЗапись = НаборЗаписейИсторияОбъектов.Добавить();
        
        НоваяЗапись.Период = ТекущаяДата();
        
        НоваяЗапись.Реквизит = ИмяРеквизита;
        
        НоваяЗапись.ИмяКомпьютера = ИмяКомпьютера();
        НоваяЗапись.Пользователь = ПараметрыСеанса.ТекущийПользователь;
        НоваяЗапись.РаспределеннаяБаза = ПараметрыСеанса.ТекущаяРаспределеннаяБаза;
        НоваяЗапись.СтароеЗначение = Ссылка[ИмяРеквизита];
        НоваяЗапись.НовоеЗначение = ЭтотОбъект[ИмяРеквизита];
        
    КонецЕсли;
    
КонецПроцедуры

Пример приведен для иерархического подчиненного справочника.

Если брать другой объект, например, документ, то состав служебных реквизитов будет другой, не «Код», «Наименование», «Родитель» и «Владелец», а «Дата» и «Номер».

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

Замаялся.

От Гения 1С: Смотрите Книга знаний: v8: Парциальная регистрация изменений в базе данных

Просмотр истории значения реквизита справочника

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

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

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

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

Для просмотра истории значения поместите курсор в строку с НУЖНЫМ элементом справочника и выполните одно из следующих действий: нажмите клавишу F5 или нажмите кнопку (7) в панели инструментов окна справочника или выбрать пункт «История значения» в меню «Действия» главного меню программы.

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

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

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

| опубликовано: 14 Август, 20:20

Содержание:

1.       Журнал регистрации событий

2.       Как посмотреть историю действий пользователя

3.       Версионирование — история данных

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

Для определения действий пользователя в 1С можно использовать следующие возможности конфигураций 1С:

— журнал регистрации событий;

— история действий;

— версионирование данных.

Кратко рассмотрим каждый из них.   

1.     Журнал регистрации событий

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

Путь к журналу регистрации событий

Журнал регистрации событий

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

Настройка журнала регистрации

После установки необходимого отбора в журнале отобразятся все события, соответствующие отбору, где можно увидеть, кто и когда внес правки в те или иные данные базы. Единственное, чего не будет видно, какие именно реквизиты были отредактированы. Тут отображается факт самого события, которых тоже очень много:

Отражение событий в журнале регистрации событий   

2.     Как посмотреть историю действий пользователя

История действий пользователя – это интерфейсный механизм платформы, который может использовать любой человек, работающий в информационной системе. Этот механизм хранит все действия сотрудника компании с объектами прикладного решения. Удаление старых записей истории происходит автоматически, так как она может хранить не более 400 записей. Если человек несколько раз изменял какой-то объект базы данных, то этот механизм будет отображать только последнюю запись. Для регистров сохраняются записи про каждое изменение в разрезе его ключевых полей. Ограничением этого механизма является то, что он отображает действия того пользователя, под которым авторизовались в конфигурации. История других сотрудников будет невидна.

Чтобы посмотреть историю действий текущего пользователя нужно нажать на значок часов в правом верхнем углу:

Как посмотреть историю действий пользователя    

3.     Версионирование — история данных

Версионирование данных– это наиболее подробная история изменения данных, точнее это механизм платформы 1С, позволяющий хранить эту историю. Чтобы можно было использовать механизм версионирования истории данных, требуется его предварительное включение. Для этого нужно установить флажок «Хранить историю изменений» в разделе Администрирование – Общие настройки – История изменений.

Хранить историю изменений

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

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

Настройка механизма версионирования истории данных

Для просмотра сохраненных версий необходимо в соответствующем журнале справочника/документа встать на нужную строку и выбрать в меню Еще – История изменений или кнопку «Перейти к истории изменений»

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

Специалист компании «Кодерлайн»

Дарья Губернаторова

Иногда возникает вопрос когда, что и кто из пользователей совершил ту или иную операцию, действие в программе 1С. Кто провел документ? Кто отменил проведение документа? Кто удалил документ? Кто переместил документ на другую дату? и т.д. Стандартный журнал регистрации может ответить на эти вопросы. В журнале, правда, дается не полная информация о действии. Например, нельзя узнать какую номенклатурную позицию добавил пользователь в документ, но зато точно можно узнать открывал и вносил ли изменения пользователь в документ, справончик, регистр.
Итак, как отрыть журнал регистрации? Меню СЕРВИС — ЖУРНАЛ РЕГИСТРАЦИИ.
Собрана абсолютно вся информация о всех действиях в программе всех пользователей.
В журнале можно установить отбор по: дате, пользователю, документу, др. доступным полям.
Для точечного поиска необходимого объекта рекомендуем воспользоваться фильтром, встроенным в журнал.

Журнал очень удобен тем, что позволяет аккумулировать информацию практически неограниченный промежуток времени. Но это в свою очередь может негативно отразится на производительности базы данных, если файл журнала 1С вырастит до неприлично больших размеров. Рекомендуется периодически сокращать (урезать) через конфигуратор журнал регистрации. Делается это просто. В режиме КОНФИГУРАТОР меню АДМИНИСТРИРОВАНИЕ — НАСТРОЙКА ЖУРНАЛА РЕГИСТРАЦИИ. Перед сокращением журнала обязательно сохраните обрезаемый кусок на компьютер. Сохранять или нет журнал на ПК 1С спросит в процессе настройки процедуры сокращения журнала.
Будьте внимательны! При Выгрузке — Загрузке информационной базы 1С журнал регистрации полностью самоочищается.

Как в 1С посмотреть историю изменения документа?

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

В «Журнале регистраций» фиксируются основные действия, выполняемые в программе в определенный момент времени тем или иным пользователем.

Для того, чтобы посмотреть «Журнал регистрации», заходим в «Администрирование» -> «Обслуживание» -> «Журнал регистрации»

В появившемся окне отражаются зафиксированные события в формате: Дата, Пользователь, Событие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Чтобы воспользоваться этим механизмом администратору или пользователю не придётся изменять конфигурацию, всё необходимое уже есть в платформе. Нужно только включить.
• Этот механизм будет работать быстрее, чем аналоги, реализованные в составе конфигурации, т.к. он будет использовать возможности, недоступные из встроенного языка.
• Сама история данных будет занимать меньше места, так как будет храниться не копия данных, а только их разница с предыдущей версией. Кроме этого само версионирование можно применять не ко всем реквизитам, а только к тем, которые интересуют. Это также даст дополнительную экономию.
• Можно будет поддержать версионирование не только тех объектов, которые обладают уникальной ссылкой (справочники, документы и т.п.), но и необъектных сущностей, таких как записи регистров сведений, например.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отбор версий

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

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

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

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

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

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

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

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

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

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

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

Настройки = Новый НастройкиИсторииДанных; Настройки.Использование = Истина; Настройки.ИспользованиеПолей.Вставить(«Комментарий», Истина); Настройки.ИспользованиеПолей.Вставить(«Товары.Цена», Истина); ИсторияДанных.УстановитьНастройки(Метаданные.Документы.Заказ, Настройки);

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

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

Отбор = Новый Структура(«Данные, ИзменениеЗначенийПолей»); Отбор.Данные = Документы.Заказ.НайтиПоНомеру(«0000001»); Отбор.ИзменениеЗначенийПолей = Новый Массив; Отбор.ИзменениеЗначенийПолей.Вставить(«ПозицииЗаказа.Количество»); Версии = ИсторияДанных.ВыбратьВерсии(Отбор, «НомерВерсии, Дата, ТипИзменения, ИмяПользователя, Комментарий»);

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