Версионирование объектов в 1С

26.05.2017

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

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

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

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

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

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

Статьи и публикации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отбор версий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внутреннее устройство версионирования объектов УПП 1.3. Настройки механизма версионирования

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

Существующие версии типа документа можно просмотреть, воспользовавшись командой Версии  контекстное меню соответствующего типа документа:

В ответ система откроет таблицу со всеми версиями этого типа документа. Можно открыть любую из версий и посмотреть какая она была. Если версий больше одной, появляется доступ к контекстному меню, в котором можно установить любую версию текущей (т.е. все новые документы будут создаваться на ее основе). Такая потребность возникает крайне редко, но, если вдруг — мы о ней вам рассказали.

Журналы документов

Все документы хранятся в журналах. Журнал документов — это электронный аналог обычной бумажной папки. На экране журнал выглядит как таблица, строки которой являются документами. Например, вы можете создать журнал Приказы кадровые, который будет включать документы "Приказ о приеме на работу", "Приказ об увольнении", "Кадровое перемещение". С этим журналом будет работать пользователь-кадровик. Или можно создать отдельный журнал для банковских документов, куда войдут документы "Платежное поручение" и др.

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

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

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

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

У журнала документов есть экранная форма, где можно настраивать отображаемые колонки. Можно создавать дополнительные колонки, которые будут отображать информацию из документов. Например, в журнале ПриказыКадровые удобно сразу видеть, к какому сотруднику относится каждый документ, для этого создается Графа журнала Сотрудник

Объект Сходства Различия
Константы хранят значения, сохраняются в базе данных Документ хранит не одно значение, а событие хозяйственной деятельности предприятия, кроме того событие порождает изменение состояния данных. Документ обязательно имеет дату и время, может содержать табличную часть, хранит множество данных различных типов, которые могут быть связаны с данными других объектов. Константы не имеют печатной формы.
Справочники сохраняется в базе данных, имеет реквизиты, справочники могут быть подчиненными друг другу Могут иметь печатные формы Справочник хранит нормативно-справочную информацию, а документы отражают события реального мира. Обычно значения реквизитов документов выбираются из справочников. Документ обычно проводится, имеет дату и время. Справочники, в отличие от документов могут быть многоуровневыми, иметь периодические (привязанные к дате) реквизиты.

Версионность объектов 1с

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