Меню

1с сравнить версии объектов программно



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отбор версий

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

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

Читайте также:  Киа спортаж или тойота рав 4 сравнить

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Версионирование объектов (новые возможности «1С:Бухгалтерии 8»)

В «1С:Бухгалтерии 8» (ред. 3.0), начиная с версии 3.0.35, реализован механизм версионирования объектов, с помощью которого можно отслеживать историю изменений документов и справочников.

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

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

Использование версионирования особенно актуально на начальном этапе внедрения программы, когда объемы информации небольшие, а исполнители совершают много ошибок (например, вводят лишнюю информацию или очищают наименование или значение какого-то реквизита внутри объекта).

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

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

Объекты версионирования

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

Если для выбранного справочника или документа версионирование включено, в его форме будет доступна команда История изменений (рис. 1).

Рис. 1. Команда История изменений в форме элемента справочника.

По этой команде открывается список версий объекта (рис. 2).

Рис. 2. История изменений объекта.

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

  • Кто изменил объект?
  • Когда произошли изменения?
  • Что было изменено в объекте?

В списке выводится следующая информация:

  • — порядковый номер версии, версии перечисляются по убыванию; номеров, самая первая версия находится внизу списка;
  • Автор изменений — пользователь, который редактировал объект;
  • Дата — дата и время редактирования;
  • Комментарий — в этом поле можно ввести подробную информацию по поводу конкретной версии. Программа автоматически заполняет это поле, например, при переходе на другую версию.
Читайте также:  Сравнение nsp с аптечными препаратами

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

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

Используя соответствующие кнопки, в форме списка доступны следующие действия:

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

Обращаем ваше внимание, что при удалении объекта его история также удаляется, поэтому в этой ситуации версионирование не поможет.

Настройки хранения версий

Рис. 3. Механизм версионирования объектов в составе раздела Администрирование.

После этого становится доступной гиперссылка Настройки хранения, перейдя по которой можно произвести необходимые настройки версионирования (рис. 4).

Рис. 4. Настройки версионирования объектов.

В форме Версионирование объектов выводится список из следующих реквизитов:

  • Объект — список объектов программы в виде дерева с группировкой по типам объектов;
  • Вариант версионирования — выбранный вариант версионирования;
  • Срок хранения версий — выбранный срок хранения версий.

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

  • Не версионировать — история версий объекта не ведется;
  • Версионировать при записи — новая запись заносится в историю версий каждый раз при изменении (или создании нового) справочника или документа;
  • Версионировать при проведении – вариант применим только для документов, для которых разрешено проведение. Первая версия документа будет записана в историю только после первого проведения документа, впоследствии версии документа будут записываться при каждой записи проведенного документа. Эта настройка не позволяет создавать версии новых не заполненных окончательно документов, которые приводят к увеличению объема хранимой в программе информации;
  • Версионировать при старте — этот вариант применим только для бизнес-процессов. Первая версия бизнес-процесса будет записана только после его старта. Режим позволяет не создавать лишние версии бизнес-процессов в то время, пока их подготавливают к запуску;
  • По умолчанию — установить рекомендуемые настройки (для справочников — Не версионировать, для документов — Версионировать при проведении).

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

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

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

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

Команды Установить вариант версионирования и Установить срок хранения версий также можно найти в меню Еще или в контекстном меню, вызываемом правой кнопкой мыши.

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

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

Для того, чтобы устаревшие версии удалялись автоматически, необходимо включить соответствующий флаг и перейти по гиперссылке Настроить расписание (рис. 5). Настроенное расписание будет выводиться в нижней части окна.

Рис. 5. Настройка регламентного задания по удалению устаревших версий.

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

Источник