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

В базах 1С есть журнал регистрации, куда по умолчанию записывается вся информация и ошибки системы и действия пользователей с данными. Если вы активно работаете с программой 1С, выписываете счета, вносите, изменяете данные, то все эти действия отражаются в журнале регистрации и из-за этого журнал уже после года работы может вырасти более чем на 1Гб. Конечно, на данный момент 1Гб занимаемого дискового пространства не такая уж и большая величина, если учесть, что сейчас объем жестких дисков измеряется терабайтами. Но сейчас, все чаще мы начали использовать SSD (твердотельные) диски, в которых показатель свободного пространства достаточно существенен. Если с базой работает только вы, т.е. один пользователь, то журнал регистрации можно настроить только на запись ошибок или ошибок и предупреждений. Если в базе есть несколько пользователей, то тут уже на ваше усмотрение, включать полный учет всех действий или нет. Настроить работу журнала регистрации можно через конфигуратор. Войдите в базу 1С через конфигуратор с полными правами. Далее нажмите «Администрирование» -> «Настройка журнала регистрации…».

После этого появится окно, где можно будет выбрать режим работы журнала регистрации. Если у вас новая база и вы решили сразу настроить журнал регистрации, то после выбора можете сразу нажимать «OK» и продолжить работу с 1С.

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

В этом окне вы можете выбрать до какой даты сократить журнал регистрации, если вы никогда не заглядывали в журнал регистрации, то можете смело выбирать текущую дату и сокращать весь журнал. Так же есть опция, которая позволяет сохранить удаляемые данные в отдельный файл на всякий случай. Пользоваться этой опцией или нет, это на ваше усмотрение. После выбора даты и выбора файла сохранения или только выбора даты нажимаем «ОК» и программа начнет сокращение журнала. Процесс может занять не которое время и на время сокращения журнала, работать с базой не получиться. Если вы выбрали сокращение журнала регистрации с сохранением удаляемых данных в отдельный файл, то этот процесс может занять значительное время, например, файл журнала размером 12Гб, сокращается 2 часа.

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

Учитывайте это при планировании регламентных работ с базой 1С.

Журнал регистрации в базах 1С может храниться в старом и новом формате. Если используется старый формат, то в файловой базе 1С в папке «1Cv8Log» будут содержаться файлы с расширением *.lgf и *.lgp, если формат журнала новый, то расширение файла *.lgd

старый формат журналановый формат

Если у вас старый формат журнала, то после сокращения размер файлов уменьшится самостоятельно, а вот с новым форматом журнала придется сделать еще одну процедуру, т.к. размер файла не меняется после сокращения журнала. Все дело в том, что новый формат журнала регистрации использует формат SQLite для хранения данных и программа 1С не сокращает файл журнала «1Cv8.lgd» самостоятельно, поэтому нужно в ручную выполнить команду vacuum для файла «1Cv8.lgd». Для этого нам понадобиться программа sqlite3.exe, её можно скачать с сайта sqlite.org. На странице загрузки находите раздел «Precompiled Binaries for Windows» и в нем скачиваете файл
«sqlite-tools-win32-x86-3260000.zip», последние цифры в имени файла могут изменяться, когда меняется версия программы sqlite3.exe.

После того как скачали архив с программой распаковывайте его, например, в папку temp, которая располагается в корне диска C: (C:\temp), для удобства переименовываете папку «sqlite-tools-win32-x86-3260000» в «sqlite». После этого открываете командную строку от имени «Администратора системы». Далее командой в консоли «cd C:\temp\sqlite» переходите в папку с файлом sqlite3.exe. Теперь вы можете выполнить команду vacuum для файла «1Cv8.lgd». Формат команды будет примерно такой «sqlite3.exe C:\<путь к файлу>\1Cv8.lgd vacuum»

sqlite3.exe C:\<путь к файлу>\1Cv8.lgd vacuum

И вот тут как раз есть одна проблема, если в пути к файлу «1Cv8.lgd» будут русские буквы, т.е. имена папок будут содержать русские буквы, то команда не выполниться и выдаст ошибку, что не может найти файл «1Cv8.lgd». Решение этой проблемы достаточно простое, нужно файл sqlite3.exe скопировать в папку «1Cv8Log», перейти в эту папку в командной строке и выполнить команду без указания пути «sqlite3.exe 1Cv8.lgd vacuum» , т.к. файл «1Cv8.lgd» находится в том же каталоге что и программа sqlite3.exe. Один важный момент, данную операцию нужно выполнять, когда программа 1С не запущена, т.е. ни кто не работает с базой, журнал которой вы сокращаете.

Получилось достаточно много шагов и нюансов для уменьшения размера файла «1Cv8.lgd», но для своего и вашего удобства я сделал bat файл, который выполнит нужную нам команду без открывания командной строки. Вам нужно скачать архив с bat файлом и программой sqlite3.exe с моего репозитория на GitHub по этой ссылке https://github.com/ProfAdmin/archive/raw/master/sqlite_for_1C.rar. После скачивания, распаковываете файлы, копируете их в папку «1Cv8Log» и запускаете файл «vacuum_1Cv8LGD.bat».

Откроется окно консоли, выполнится команда vacuum и вам нужно будет нажать на любую клавишу для закрытия окна, после этого файл «1Cv8.lgd» будет сокращен. После вы можете удалить скопированные файлы из папки «1Cv8Log», кроме «1Cv8.lgd» или оставить для будущего сокращения.

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

Журналы документов — это вторичные данные, не несущие никакой первичной информации и являющиеся не более чем еще одним представлением списка документов.

Работа с документами в 1С построена на моментах времени (большинство операций происходят последовательно — например, сначала покупка, потом продажа). При этом каждый документ имеет свой список. При одновременной работе со списками нескольких документов связь этих документов на основе линии времени может не прослеживаться. Объект 1С «Журналы документов» позволяет показать порядок документов в общем списке документов.

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

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

Например, на складе товар привозят (оприходование) и увозят (отгрузка, реализация). Это два разных документа (списка). Журнал позволяет объединить оба документа в один список и показать пользователю общие (одинаковые) поля, которые есть у разных документов.

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

В 1С:Предприятии 8 в конфигурации можно создать несколько объектов метаданных «Журнал документов». В метаданных для журнала документов:

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

Рисунок «Журналы документов» 1С

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

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

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

Особенности использования «Журналов документов» 1С:

  1. В файловом варианте информационной базы транзакционные блокировки устанавливаются на таблицу базы данных, поэтому параллельность работы с документами зависит от того, какие существуют в конфигурации журналы. Одновременно не может выполняться запись двух документов входящих в один журнал.
  2. В клиент-серверном варианте, так как блокировки устанавливаются на уровне записей, наличие журналов не влияет на параллельность записи документов, кроме отдельных случаев, когда сервер баз данных повышает при записи уровень блокировки.
  3. В большинстве случаев не следует создавать журналы, содержащие все виды документов конфигурации, а следует рассматривать создание журналов, включающих те или иные группы документов.
  4. Число документов, регистрируемых в одном журнале, не ограничено. Но создание журналов документов, регистрирующих все или большую часть видов документов, допустимо только для конфигураций, которые заведомо рассчитаны на небольшое число одновременно работающих пользователей.
  5. Рекомендуется создавать графы для отображения в журнале только наиболее существенной информации из документов.
  6. В конфигурациях, содержащих относительно небольшое количество документов и рассчитанных на пользователей, имеющих некоторое представление о совокупности всех документов данной конфигурации, могут использоваться журналы с большим количеством видов документов, то есть включающие широкие группы документов, например все документы, отражаемые в бухгалтерском учете.
  7. Число журналов, в которых может регистрироваться один вид документа, не ограничено. Однако такая регистрация несколько «утяжеляет» процедуру записи и удаления документа. Для документов, которые не имеют табличных частей, накладные расходы на регистрацию документа в журналах могут быть сопоставимы с расходами на собственно запись документа, и даже превышать их.

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

Работа с журналами документов

Работа с журналами документов при реструктуризации

Таблица журнала документов имеет следующий состав полей:

  1. Стандартные реквизиты:
    • «Ссылка» — ссылка на регистрируемый в журнале документ;
    • «Дата» — дата регистрируемого документа;
    • «Номер» — номер регистрируемого документа, поле существует, если хоть один из регистрируемых документов имеет номер с длиной отличной от нуля;
    • «Тип»;
    • «Проведен» — пометка проведенности регистрируемого документа;
    • «ПометкаУдаления» — пометка удаления регистрируемого документа;
  2. Поля, соответствующие графам документа — содержимое соответствующих реквизитов регистрируемых документов.

Рисунки «Стандартные реквизиты и графы Журнала документов 1С

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

  1. производятся манипуляции с самим журналом или подчиненными ему объектами конфигурации — графами журнала:
    • изменяется состав граф журнала документов или состав включенных в графы реквизитов документов;
    • в журнал включается еще один существовавший ранее вид документов;
    • из журнала исключается вид документов;
  2. производятся манипуляции с документами, включенными в журнал:
    • изменяется тип или длина номера документа, включенного в журнал;
    • изменяется тип реквизита документа, включенного в одну из граф документа;
  3. в журнал включается вид документов, созданный при текущем сеансе конфигурирования.

Замечание по п.3

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

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

Работа с журналами документов при тестировании и исправлении информационной базы

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

Работа с журналами документов при записи документов

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

  1. при записи новых документов;
  2. при записи документов, у которых есть любые изменения:
    • в реквизитах самого документа (изменения в табличных частях не приводят к необходимости «перерегистрации» в журналах документов);
    • изменение даты документа;
    • изменение номера документа;
    • изменение признака проведенности;
    • изменение пометки удаления.

Во всех этих случаях также выполняется «перерегистрация» во всех журналах документов, в которых регистрируется документ.

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

Оптимизация отбора по графам журнала

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

См. также Свойства и методы прикладных объектов

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

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

Где найти журнал регистрации в 1С 8.3? Через меню «Все функции» — «Стандартные» или, в типовых конфигурациях 1C, в меню «Администрирование» — «Поддержка и обслуживание».

Настройка

Настройка журнала регистрации производится в режиме конфигуратора. В меню «Администрирование» выберите пункт «Настройка журнала регистрации».

Наша команда предоставляет услуги по консультированию, настройке и внедрению 1С.
Связаться с нами можно по телефону +7 499 350 29 00.
Услуги и цены можно увидеть по .
Будем рады помочь Вам!

Здесь настраиваются те события, которые будут отображаться в журнале регистрации.

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

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

Просмотр и поиск записей

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

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

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

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

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

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

Где хранится файл журнала 1cv8.lgd

Место физического хранения журнала регистрации напрямую зависит от того, файловая база или клиент — серверная.

Файловая база

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

Если перейти по данному адресу, вы найдете папку с именем «1Cv8Log». Именно тут расположены данные журнала регистрации в файле 1Cv8.lgd.

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

При удалении данного каталога, журнал регистрации очистится.

Клиент-серверная база

В таком режиме все так же, как и в предыдущем, только данные журнала регистрации 1С хранятся на сервере. Чаще всего его место расположения следующее:

  • C:\Program Files\1cv8\srvinfo\<место расположения информационной базы>\1Cv8Log

Оптимизация

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

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

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

Начиная с версии платформы 1С 8.3.5.1068, журнал регистрации хранится в файле базы данных sqlite с расширением *.lgd, и данная настройка стала недоступна. Данный способ хранения журнала регистрации значительно производительнее, чем старый.

Как уменьшить или удалить журнал регистрации в 1С

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отбор версий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассказать друзьям:

Оставить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *