>
-->
Содержание

Системные требования

Версия платформы «1С: Предприятие»

8.2.13.202 и выше

Виды поддерживаемых конфигураций

Обычное приложение, управляемое приложение, WEB

Вариант «1С:Предприятие»

Клиент-серверный, файловый

Рекомендуемое разрешение экрана

1024x768

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

Управляемые или автоматические (автоматические и управляемые не поддерживаются. Только перевод либо на управляемые блокировки.)

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


Интеграция в конфигурацию

Подсистема интегрируется с любой конфигурацией «1С:Предприятие 8.2» и «1С:Предприятие 8.3».

Установка подсистемы в основную конфигурацию

1) Установите дистрибутив поставки конфигурации, нажав setup.exe из полученного Вами дистрибутива (запомните путь, куда будет установлен дистрибутив подсистемы).

2) Зайдите в конфигуратор информационной базы. Конфигурация может находиться на поддержке без возможности изменения (возле каждого объекта могут быть «замочки»). «Замочки» означают, что конфигурацию нельзя редактировать. Если замочков уже нет, идем к шагу 6.

1.png

3) Для того, чтобы открыть возможность редактирования конфигурации зайдите в меню: «Конфигурация>Поддержка>Настройка поддержки»

2.png

4) Включите возможность изменения конфигурации.

3.png

После этого будет задан вопрос:

4.png

 

Необходимо нажать «Да». Далее появится окно:

5.png

 

Необходимо выбрать указанный пункт и нажать OK, немного подождать и закрыть окно «Настройка поддержки».

5) После того как возможность изменения будет включена необходимо сохранить конфигурацию. Для этого нажмите F7.

6) В меню выберите пункт «Конфигурация>Сравнить и объединить с конфигурацией из файла»:

6.png

7) После чего укажите файл 1Cv8.cf из каталога установленного дистрибутива нашей подсистемы на первом шаге и подпапке «journ», например, в Windows 7 путь будет следующим:

«c:\Users\<Имя учетной записи>\AppData\Roaming\1C\1Cv82\tmplts\journ\»).

Будет задан вопрос о постановке на поддержку:

7.png

Нажимаем «Да».

8) Откроется окно сравнения, объединения с конфигураций. В этом окне необходимо снять флажок с корневого элемента дерева. Будут сняты все флажки.

8.png

9) Нажимаем в этом окне «Действия>Отметить по подсистемам файла»

9.png

Выбираем указанные флаги и нажимаем «Установить».

10) После этого в подсистемах устанавливаем флаг возле строки «внЖурналРегистриации» (в дереве объектов Общие>Подсистемы).

10.png

11) Нажмите кнопку «Выполнить». Появится диалоговое окно:

11.png

Нажмите «OK». После чего сохраните конфигурацию нажав F7.

12) Теперь необходимо добавить служебный код, чтобы подсистема смогла работать при запуске:

12.png

Правой кнопкой по корню конфигурации и можно открыть любой модуль

Для управляемого приложения (управляемое приложение):

 

В начало процедуры ПриНачалеРаботыСистемы:

Процедура ПриНачалеРаботыСистемы()
                //<< вн
                внЖурналРегистрацииКлиент.ПриНачалеРаботыСистемы();
                //>>

 

Процедура ПриНачалеРаботыСистемы()

                //<< вн

                внЖурналРегистрацииКлиент.ПриНачалеРаботыСистемы();

                //>>

 

В конец процедуры ПриЗавершенииРаботыСистемы (если ее нет, создать):

 

Процедура ПриЗавершенииРаботыСистемы()

                …

                // Добавляем в конец процедуры

                //<< вн

                внЖурналРегистрацииКлиент.ПриЗавершенииРаботыСистемы();

                //>>

КонецПроцедуры

Модуль внешнего соединения должен выглядеть вот так:

Процедура ПриНачалеРаботыСистемы() 

                //<< вн

                внЖурналРегистрацииКлиент.ПриНачалеРаботыСистемы();

                //>>

КонецПроцедуры

Процедура ПриЗавершенииРаботыСистемы()

                //<< вн

                внЖурналРегистрацииКлиент.ПриЗавершенииРаботыСистемы();

                //>>     

КонецПроцедуры

Модуль сеанса (если процедуры УстановкаПараметровСеанса нет, то создать ее):

Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)

                //<< вн

                внЖурналРегистрации.УстановкаПараметровСеанса(ТребуемыеПараметры);

                //>>

КонецПроцедуры

 В конфигурациях на основе БСП (Бухгалтерия предприятия 3.0, Управление торговлей 11.2 и т.п.) в последних версиях появилась необходимость в общий модуль ПользователиПереопределяемый в процедуру ПриОпределенииНазначенияРолей добавить:

… НазначениеРолей.ТолькоДляПользователейСистемы.Добавить(Метаданные.Роли.внАдминистраторЖурналаРегистрации.Имя); НазначениеРолей.ТолькоДляПользователейСистемы.Добавить(Метаданные.Роли.внПросмотрЖурналаРегистрации.Имя);
Это необходимо, делать только в конфигурациях на базе БСП, если в вашей конфигурации нет такого общего модуля и аналогичной процедуры в нем, то добавлять туда ничего не нужно.

Если указанные процедуры уже существуют, необходимо добавить в них все блоки, которые начинаются с //<< вн и заканчиваются //>>, если этих процедур нет, необходимо их создать.

Для обычного приложения (обычные формы)

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

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

 

13) Откройте в конфигураторе в меню: «Администрирование>Пользователи» и у текущего пользователя, под которым происходит интеграция подсистемы, добавьте права «(ВН) Администратор журнала регистрации», для того, чтобы в режиме предприятия после запуска этого пользователя можно было настроить наш журнал регистрации:

13.png

 

Важно! Если в конфигурации нет пользователей, то их необходимо их создать! Без пользователей подсистема не будет работать!

14) Последний пункт. Если ваша информационная база работает на основе библиотеки стандартных подсистем, она же БСП, то необходимо в параметрах запуска указать дополнительный параметр запуска:

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

А) Запуск из конфигуратора.

В конфигураторе Меню > Сервис > Параметры вкладка Запуск 1С:Предприятие в поле «Параметры запуска» указать «/С ЗапуститьОбновлениеИнформационнойБазы». Пример:

Параметры в конфигураторе

Потом выполнить запуск конфигурации в режиме предприятия из конфигуратора нажав «Начать отладку» (или F5).

Б) Запуск в режиме предприятия без отладки.

Нажмите кнопку «Изменить», затем «Далее», «Далее» и на указанной как в скриншоте ниже странице измените дополнительные параметры запуска:

Указание параметров запуска

Настройка подсистемы в конфигураторе завершена. Запускайте конфигурацию в режиме предприятия.


Установка и настройка внешней ИБ «Хранитель журнала регистрации»

1)      Установите дистрибутив поставки конфигурации, нажав setup.exe из полученного Вами дистрибутива из папки «Хранитель журнала регистрации».

2)      Далее откройте окно открытия конфигурации и добавьте новую информационную базу хранителя.

14.png

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

4)      После открытия назначьте добавленному пользователю «Администратор» пароль, чтобы в базу хранителя никто не смог зайти кроме администраторов. Добавить пароль: «Настройка и администрирование > Настройка пользователей и прав > Пользователи». Откройте пользователя Администратор и установите ему пароль в поле «Пароль» и «Подтверждение пароля». После чего нажмите «Записать и закрыть».

5)      Конфигурацию хранителя можно считать установленной и готовой к работе.

 

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

Обновление подсистемы на более новую версию в рабочей информационной базе

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

Как их устанавливать? Об этом по порядку…

1)      Устанавливаем дистрибутив обновления, который мы Вам выслали. Запоминаем путь, куда установилось обновление. Далее заходим в конфигуратор. Выбираем в меню «Конфигурация > Поддержка > Обновить конфигурацию». В открывшемся окне «Выбор файла обновлений», нажимаем «Далее». Выбираем cfu-файл и нажимаем «Готово».

2)      После, того как мы выберем cfu-файл с обновлением, конфигурация спросит у нас:

15.png

Щелкнем «ОК».

3)      В появившемся окне снимем все галочки для свойств конфигурации:

 Остальные галочки необходимо оставить

16.png

 

4)      Далее необходимо поставить галочку в дереве метаданных «Общие > Подсистемы > внЖурналРегистрации»

5)      Так же мы можем Вас попросить в письме с обновлением прислать дополнительные инструкции.

6)      Нажимаем на кнопку «Выполнить»

7)      После всего необходимо обновить конфигурацию базы данных, нажав F7 или кнопку:

11111.png

 

8)      После этого необходимо запустить конфигурацию в режиме предприятия под пользователем с полными правами и правом «(ВН) Администратор журнала регистрации».

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

10)   Готово. Подсистема обновлена.

Обновление информационной базы «Хранитель журнала регистрации»

Конфигурация с хранителем обновляется точно так же, как и любая другая конфигурация от 1С.

Настройка связи подсистемы с конфигурацией «Хранитель журнала регистрации»

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

Открываем конфигурацию в режиме предприятия и идем в раздел «Внешний журнал регистрации». Далее, открываем пункт «(ВН) Настройка журнала регистрации»:

17.png

2) Включаем флаг «Вести историю изменений». Эта опция включает/отключает запись всех изменений.

3) На этом шаге необходимо подключить текущую рабочую информационную базу к «Хранителю журнала регистрации». В группе «Хранитель журнала регистрации» на скриншоте выше указываем тип базы хранителя (файловая/серверная), версию 1С ИБ хранителя, путь к базе хранителя (если ИБ файловая), имя сервера и имя базы (если ИБ серверная), пользователь и пароль. После чего необходимо нажать кнопку «Проверить соединение». Получаем примерно следующее:

18.png

 

4) Так же необходимо задать идентификатор информационной базы, который будет отличать одну информационную базу от другой. Т.к. в «Хранителе журнала регистрации» могут храниться данные изменений разных информационных баз, то идентификатор должен быть уникальным в пределах одной базы. Если используется РИБ, то идентификаторы каждой из баз РИБ должен быть одинаковым. Уделите этому параметру особое внимание, т.к. из не правильной установка этого параметра подсистема может работать не корректно. Например, если есть РИБ базы УПП (УПП главная, УПП дочерняя 1, УПП дочерняя 2), то у них идентификатор должен быть одинаковым допустим «УПП», если же мы позже подключим конфигурацию «Зарплата и управление персоналом», то идентификатор для этой базы должен быть отличным от «УПП», допустим это будет «ЗУП» в таком случае все будет работать корректно.

5) Перейдите на закладку «РИБ» и установите идентификатор узла РИБ (о нем написано ниже). Это простая строка, заполните и укажите идентификатор, например, «Главная ИБ».

6) Далее настраиваем историю по своему усмотрению. Все настройки отдельно описаны ниже.

Настройка подсистемы

В толстом клиенте настройку можно открыть из «Меню>Операции>Обработки>(ВН) Журнал регистрации». В тонком появится дополнительная вкладка на рабочем столе. Обязательно пройдитесь по всем вкладкам и настройте подсистему.


Закладка «Настройки истории»

Флаг «Вести историю изменений» позволяет включать/отключать запись во внешний журнал регистрации.

 

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

 

Далее идут настройки доступа к ИБ «Хранитель журнала регистрации»

 

Параметры уникальности (на закладке «Настройки истории») – это уникальный механизм защиты от записи истории объектов в клонах информационных баз. Часто, необходимо сделать копию информационной базы для тестирования доработок, экспериментов и т.д. При этом наша подсистема будет работать только в работающей конфигурации, в копиях-клонах работать она не будет. Эта особенность пригодится программистам, т.к. позволит не думать, что копия будет добавлять свои события в историю. После переноса базы-оригинала на новый сервер нажмите на кнопку «Текущая ИБ» и после этого запись событий будет осуществляться для перенесенной ИБ 1С. При необходимости проверку на уникальность можно отключить, убрав флаг, который находится с полем текущего параметра уникальности.

 

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

Важно! Не изменяйте данный идентификатор! Он должен быть назначен только один раз при начале работы. Иначе Вы потом не будете видеть всю историю по объектам до смены идентификатора!

Отключение стандартного журнала регистрации

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

Для отключения стандартного журнала регистрации зайдите в конфигурацию с административными правами, убедитесь, что в режиме предприятия с конфигурацией никто не работает, в меню «Администрирование > Настройки журнала регистрации…», выберите пункт «Регистрировать ошибки»:

32.png

После этого нажмите «ОК».

Все. Теперь в типовом журнале регистрации будут регистрироваться только ошибки.

Запуск регламентных заданий по переносу кэша журнала регистрации

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

Если у вас конфигурация на основе БСП (УТ11, КА, УНФ и т.д.), Вам необходимо создать регламентное задание в режиме предприятия. Для этого перейти во вкладку «Администрирование», там выбрать «Поддержка и обслуживание», в открытой обработке «Регламентные и фоновые задания».

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

27.png

 

Запуск регламентных заданий в файловом и клиент-серверном варианте работы конфигурации отличается. Рассмотрим их по порядку:

 

Вариант 1. Клиент-серверный вариант и файловый вариант (для 8.3)

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

 

Вариант 2. Файловый вариант работы (только для 8.2)

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

28.png

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

29.png

Либо запускать фоновые задания через планировщик Windows:

В конфигурации создайте пользователя в режиме предприятия, при создании уберите галочку «Показывать в списке выбора». Задайте ему имя и пароль. Установите для него полные права. Это пользователь, под которым будут автоматически запускаться регламентные задания.

30.png

 Далее, откройте «Панель управления > Все элементы панели управления > Администрирование» компьютера, где будут запускаться регламентные задания. Желательно (но не обязательно), чтобы этот компьютер был постоянно включенным.

31.png

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

Параметр

Описание

DoScheduledJobs

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

SkipMessageBox

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

AloneIBSession

Запустить сеанс только для выполнения регламентных заданий. Если сеанс для целей выполнения заданий уже открыт, то открываемый сеанс будет завершен с предупреждением (или без предупреждения см.SkipMessageBox).

 

Примеры строки программы в ярылке Windows.

Назначение

Строка

Включить выполнение заданий в открываемом сеансе.

"C:\Program Files\1cv82\Bin\1cv8c.exe" /CDoScheduledJobs

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

"C:\Program Files\1cv82\Bin\1cv8c.exe" ENTERPRISE /F"C:\Инфорационная база"; /NВасилий /PПароль /C"DoScheduledJobs SkipMessageBox AloneIBSession".

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

"C:\Program Files (x86)\1cv82\8.2.17.169\bin\1cv8c.exe" ENTERPRISE /F"C:\buh"; /N"Администратор" /P112233 /C"DoScheduledJobs SkipMessageBox AloneIBSession"

Для тестирования работы запустите команду Выше (с учетом расположения своей базы, логина, пароля, а так же версии платформы) нажав Windows + R и в открывшемся окне вставить и запустить указанный пример. Должен запуститься сеанс 1С:Предприятие, в котором будет работать обработка.

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

Закладка «Дополнительно»

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

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

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


26.png

Способ определения представления

Эта настройка может принимать два значения:

 

1)      При регистрации

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

 

2)      В регламентном задании

Способ, который очень быстро работает. Значительно быстрее первого варианта, но он менее гибок. Реквизиты, которые записываются для всех реквизитов объектов, не записываются построчно, а записываются скопом. Это работает гораздо быстрее, но если вы захотите установить отбор по событиям, у которых в изменениях есть такое-то значение реквизита, то у Вас для событий, которые еще находятся в кэше ничего не получится. Конечно, если регламентное задание по переносу кэша настроено на выполнение один раз в 60 секунд, то вполне возможно вы и не столкнётесь с подобным. Так же этот способ необходимо использовать, когда количество одновременно работающих пользователей более 50.

 

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

Закладка «Мониторинг журнала»

 

Эта вкладка предназначена для просмотра состояния кэша журнала регистрации и количества записей во внешней ИБ хранилища.

25.png

 Тут же можно перенести данные из локального кэша во внешнюю ИБ хранилища или запустить обработку в базе «Хранителя».



Закладка «Начальное заполнение»

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

Целесообразно ее использовать только один раз в самом начале эксплуатации так же этот этап лучше использовать, если информационная база не очень большая.

При этом для объектов, которые привязаны к периоду могут быть записаны только объекты за последние N дней, где N – определяется пользователем при начальном заполнении. Что это за объекты, привязанные к периоду? Это: документы (дата документа), регистры сведений (подчиненные регистратору и периодические), задачи и бизнес-процессы. При первоначальном заполнении их выборка может быть ограничена тем количеством дней, который актуален в данный момент. Для больших информационных баз рекомендуется установить «Не регистрировать объекты старше» 60 дней (чем больше база, тем меньше установите значение). Можно поставить 30, 15 и т.д.

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

 

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

Назначение ролей через профили доступа

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

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

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

23.png

 В этой форме нажимаем «Записать» (значок дискетки) и переходим на дополнительный пункт «Группы доступа» пункта «Перейти», здесь же. Добавляем туда группу доступа:

24.png

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

Все! Теперь при изменении любых прав выбранные права на наш журнал регистрации не будут пропадать.

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

Закладка «Роли истории»

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

 

В режиме предприятия роли выглядят следующим образом:

  

21.png

Роль (1) – кто может просматривать журнал регистрации;

Роль (2) – кто является администратором журнала регистрации.

Роль (3) – не фиксировать события этого пользователя

 

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

 

Роли в конфигураторе выглядят следующим образом:

  

22.png

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

 

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

 

Важно! Если Вы используете конфигурацию на основе Библиотеки Стандартных Подсистем (УТ11, БП 3.0, ЗУП 3.0, КА, УНФ и т.д.). Подход с правами пользователей меняется. Об этом в следующей главе.

Закладка «Регистрируемые объекты»

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

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

 

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


Закладка «РИБ»

РИБ – это распределенная информационная база. Если у вас нет РИБ или Вы не знаете, что это такое, пропустите данный пункт.

В нашей подсистеме реализовано два типа обмена при использовании РИБ:

 

·         Обмен через РИБ "Хранитель журнала регистрации";

·         Обмен кэшем журнала регистрации через типовой РИБ;

 

Подробнее мы их рассмотрим ниже.

 

Идентификатор узла РИБ предназначен для отметки текущего узла РИБ. Это строка, которая отличает одну базу РИБ от другой. Этот идентификатор должен быть для каждого узла разным. Для нашего примера с УПП для баз (УПП главная, УПП дочерняя 1, УПП дочерняя 2) идентификатор ИБ будет УПП, а для каждого из этих УПП идентификаторы узлов РИБ будут разными (например, Главная, Дочерняя 1, Дочерняя 2).

 

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

Рассмотрим по порядку, типы обмена, реализованные в нашей подсистеме:


Обмен кэшем журнала регистрации через типовой РИБ

Если выбран данный тип, то в дочерних узлах нельзя посмотреть журнал регистрации, там не происходит сжатия объектов. Историю изменений объекта можно посмотреть ТОЛЬКО в главном узле РИБ.

  

19.png

Схема работы по шагам, следующая:

1.       При изменении объекта в дочерней базе РИБ, происходит запись полного образа объекта в справочник-кэш журнала регистрации;

2.       При обмене с центральной базой РИБ происходит передача всех данных об изменениях из справочника-кэша дочерней базы РИБ в справочник-кэш главной базы РИБ;

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

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

 

Плюсы:

+        Фиксируется какой пользователь РИБ сделал изменения объекта;

+        Фиксируется в какой информационной базе сделаны изменения объекта;

+        Реализуется обмен типовыми средствами РИБ;

Минусы:

-        Нет возможности посмотреть журнал регистрации в дочерних базах РИБ. Анализ изменений можно провести только в главной базе РИБ.

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

 

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

Как использовать?

Для включения данного типа обмена необходимо:

1)      Во всех базах 1C установить галочку «Вести историю изменений».

2)      Во всех дочерних базах 1С НЕ ЗАПОЛНЯТЬ на закладке «Настройки истории» параметры доступа к базе хранителя и оставить поля пустыми.

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

3)      Открыть план обмена, по которому осуществляется обмен в РИБ в режиме конфигуратора и включить в план обмена следующие объекты:

·         Справочник.внКэшЖурналаРегистрации

·         РегистрСведений.внИзменения

·         РегистрСведений.внНеРегистрируемыеОбъекты

4)      Установите регламентное сжатие журнала регистрации в главной информационной базе таким образом, чтобы сжатие приходилось на тот момент, когда все обмены с подчиненными базами уже произведены, это важно!

5)      Журнал настроен на работу в РИБ с данным типом.

 

Обмен через РИБ "Хранитель журнала регистрации"

Схема работы данного типа в РИБ:

  

20.png

Суть такова, что РИБ организовывается в ИБ «Хранитель журнала регистрации».

В отличие от предыдущего типа обмена, этот тип имеет свои преимущества и недостатки:

 

Плюсы:

+        Фиксируется в какой узле РИБ основной базы сделаны изменения объекта;

+        Объем передаваемых данных по РИБ основной базы не увеличится и останется на прежнем уровне;

+        В каждом из дочерних узлов РИБ можно использовать свой журнал изменений;

+        Реализуется обмен типовыми средствами РИБ;

+        Гибкие настройки выгрузки данных в дочерние базы РИБ хранителя (по информационной базе/по узлам РИБ/по дате выгрузки)

Минусы:

-        Необходим отдельный обмен между узлами хранителя журнала регистрации;

-        Определение изменений происходит только в главном узле хранителя и потом «спускается» по цепочке в дочерние узлы;

-        Т.к. в файловых базах 1С есть ограничения в 4 Гб на одну таблицу, то в некоторых случаях использование файловых баз хранителя в филиалах может быть затруднительно, т.к. объемы изменений могут быть больше чем 4 Гб. Это следует учитывать. Хотя на этом этапе могут помочь правильная настройка очистки данных в базе хранителя.

 

Какой из способов подходит больше – выбирать Вам!

Регистрация событий открытия и закрытия форм объектов ссылочных типов

Наша подсистема позволяет регистрировать такие события как открытие и закрытие форм объектов ссылочных типов (Справочники, Документы, ПВХ, Планы счетов, ПВР, Бизнес-процессы и Задачи). Для этого в форме объектов добавьте:

 

&НаКлиенте

Процедура ПриОткрытии(Отказ)

                // << вн

                внЖурналРегистрацииКлиент.внПриОткрытии(Объект, "ФормаЭлемента");

                // >>

КонецПроцедуры

 

&НаКлиенте

Процедура ПриЗакрытии()

                // << вн

                внЖурналРегистрацииКлиент.внПриЗакрытии(Объект, "ФормаЭлемента");

                // >>

КонецПроцедуры

 

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

 

В результате в журнале появятся записи со своими значками открытия и закрытия форм.

Работа с подсистемой журнала регистрации

Внешний вид

Открыть журнал регистрации можно следующим образом:

33.png

 Открыть журнал регистрации могут пользователи, которые имеют одну из следующих ролей: «(ВН) Просмотр журнала регистрации» или роль «(ВН) Администратор журнала регистрации».


Для открытия журнала регистрации щелкните по пункту «(ВН) Журнал регистрации».

В появившемся окне Вы увидите все изменения внешнего журнала регистрации.

Опишем все кнопки в журнале:

  

34.png

(1)    Кнопка для вызова отбора в журнале регистрации.

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

(3)    Отбор только по событиям, в которых были изменения.

(4)    Отключение всех отборов.

(5)    Открыть конкретное изменение в журнале регистрации (аналогично можно щелкнуть на событие два раза мышкой).

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

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

(8)    Вывести все изменения в печатном виде для печати изменений.

(9)    Обновить события журнала регистрации. Журнал регистрации будет перезаполнен.

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

(11)Период выборки изменений. Если обе даты пусты, то выборка ВСЕХ изменений. Не рекомендуется очищать обе даты т.к. это может снизить производительность выборки.

 

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

  

35.png

А так выглядит табличные части этого же события:

  

36.png

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

Добавление в типовые конфигурации на управляемых формах внешней печатной формы «История по журналу регистрации»

Откройте «Администрирование» и найдите «Печатные формы, отчеты и обработки»:


54.png


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

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

Добавление в типовые конфигурации на обычных формах внешней печатной формы «История по журналу регистрации»

 В подсистеме предусмотрена возможность добавления в типовые конфигурации: ЗУП 2.5, БП 2.0, УТ 10.3 и т.д. внешней печатной формы «История по журналу регистрации»

Для этого зайдите в конфигурацию в режиме Предприятия и откройте внешние печатные формы. Для БП 2.0 это выглядит так:

51.png

 

Откроется форма:

52.png

 

После этого заполните табличную часть нужными справочниками и документами:

53.png

 

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

Добавление в управляемое приложение команды для вывода изменений объектов «История по журналу регистрации»

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

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

48.png

 После этого шага нажмите «ОК» и сохраните конфигурацию нажав клавишу F7. Теперь запустите информационную базу 1С в режиме предприятия. Видим, что появилась кнопка «История по журналу регистрации» во всех документах «Перемещение товаров»:


49.png

 

При ее нажатии будет открыт журнал регистрации с установленным отбором по этому объекту.

  

50.png


Как посмотреть активность работы пользователей?

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

47.png

Отчет ясно указывает на то, что пользователь «Абдулов (директор)» 30.07.15 работал больше всех, а вот «Иванова (бухгалтер)» практически ничего не делала… Так же ниже диаграммы располагаются сводные данные по пользователям и дням работы.

Изменения ролей у пользователей

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

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

Эта функция будет удобна для контроля изменения прав пользователей.

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

Можно просмотреть изменения на форме. Вот как это будет выглядеть:

46.png

Установка отборов

Отборы позволяют отобрать изменения по определенному критерию, который можно задать. А именно:

Закладка «Основные»

- по периоду;

- по пользователю(ям);

- по компьютеру(ам);

Закладка «Данные»

- по видам объектов (Метаданные);

- по конкретному объекту (Данные, которые изменялись);

- по вхождению конкретного объекта (Данные, которые встречались в изменениях);

- по представлению данных (подстрока);

Закладка «События»

- по типу событий.

Закладка «РИБ»

- по распределенной информационной базе

42.png
43.png
44.png
45.png

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



Как увидеть, кто изменил, что было и что стало с объектом?

Итак, документ создан нами, все хорошо, но вдруг, какой-то нерадивый пользователь изменил наш драгоценный документ. Как увидеть, кто изменил, что изменил и т.д. в деталях?

Для этого необходимо два раза щелкнуть в нашем журнале регистрации или нажать Enter в соответствующей строке журнала.

Выглядеть это будет так:

41.png

 Мы видим, что было изменено 2 реквизита: Комментарий и ответственный. Сделал эти изменения пользователь: «Абдулов (директор)» 30.07.2015 в 14:26!


Старое значение комментария было пустым, новое стало «Изменю ответственного чтобы замести следы )))» и изменился реквизит «Ответственный» поменялся с Абдулова на Любимова.

Подсистема предоставила исчерпывающую информацию об изменении.

Цветовая индикация записей в журнале

В журнале у событий есть несколько стадий:

 

1)      Запись находится в кэше и не попала во внешнюю ИБ «Хранитель журнала регистрации» (записи отражаются темно-красным цветом)

2)      События, которые находятся в базе хранителя и для них еще не определены изменения (отображаются светло-серым цветом) Т.е. эти данные, которые еще не обработаны.

3)      События, которые находятся в базе хранителя и для них были найдены изменения обработаны обычным черным цветом.

 

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

Вот записи с разными статусами:

 

37.png

 

  

38.png
39.png

Обратите внимание на поле «Статус сжатия».

 

А вот как в журнале отображаются эти записи:

40.png

Откат изменений на предыдущие версии объектов

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

Для отката к предыдущей версии станьте на изменение в журнале регистрации, которое Вы хотите «откатить» назад и нажмите на кнопку в панели как на рисунке:

55.png

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

Внимание! Откат можно провести только для объектов ссылочного типа.

Работа с конфигурацией «Хранитель журнала регистрации»

Общие положения

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

Настройки

Вот так выглядит настройки журнала:

  

56.png

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

Есть отчет по объему данных изменений.

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

57.png

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

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

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

Настройка распределенной ИБ «Хранитель журнала регистрации». Сквозной пример

Рассмотрим настройку на сквозном примере.

Пусть у нас есть две рабочие базы БП 3.0 Главная и БП 3.0 Дочерняя. Для них мы хотим настроить хранителей и использовать так же РИБ для баз хранителя.

Если вы хотите использовать распределенную ИБ хранителя, то для этого необходимо сначала настроить основную информационную базу, где в настройках, на закладке РИБ в качестве типа обмена в РИБ указать «Обмен через РИБ «Хранитель журнала регистрации» и указать уникальный идентификатор узла РИБ.

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

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

Важно! Еще раз повторю. Идентификатор информационной базы на закладке «Настройки истории» у всех рабочих баз РИБ должен быть одинаковым, а на закладке РИБ – идентификатор узла РИБ разным.

Итак, по шагам:

1)      Предполагается, что дочерняя БП 3.0 уже создана и функционирует. А в главной настроен внешний журнал регистрации.

2)      Откройте главную базу БП 3.0 и в настройках укажите:


58.png

3)      Откройте «Хранитель журнала регистрации» главной базы, зайдите в подсистему «Настройка и администрирование» выберите «Синхронизация данных». Задайте префикс и включите синхронизацию:


59.png

4)      Откройте «Синхронизацию данных» и настройте обмен:


60.png

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


61.png

Обратите внимание, в процессе настройки дочерней базы хранителя, можно задать настройки. Чтобы хранитель с дочерними базами обменивался только тем, чем необходимо. Если в филиалах в дочерних базах хотят тоже смотреть журнал по всем изменениям, то нужно указать только информационную базу. Если будет выбран узел/узлы РИБ, то в дочерней рабочей БП 3.0 можно будет увидеть только изменения в журнале по выбранным узлам, а не по базе в целом.

6)      После создания дочерней ИБ хранителя, подключим дочернюю ИБ хранителя, к дочерней БП 3.0:


62.png

63.png

7)      Проверим как работает. Сделаем изменение в дочерней БП 3.0 изменим у документа «Счет на оплату покупателю» в первой строке количество с 300 на 100:


64.png

8)      Видим, что в дочерней БП 3.0 появилось изменение в журнале:


65.png

9)      Дождемся выполнения переноса события из журнала в «Хранитель журнала регистрации» регламентным заданием (либо выполним перемещение вручную).

10)   Проведем обмен между БП 3.0 Главная <-> БП 3.0 Дочерняя.

11)   Документ с изменением был перегружен, но событие где объект был изменен не было загружено.

12)   Теперь проведем обмен между «Хранитель журнала регистрации» Главной и Дочерней.

13)   После того как в главной ИБ хранителя будет выполнено регламентное задание, по определению изменений в событиях и произойдет следующий обмен между ИБ хранителей получим в обеих рабочих базах при просмотре истории следующую картинку:


66.png

14)   При изменении реквизита «Количество» в первой строке, кроме всего прочего, за собой изменил «Сумму», «СуммуНДС» в этой же строке, а также в реквизитах документа изменилась «СуммаДокумента».

 

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

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

Важно! При использовании в филиалах вашей организации файловых баз для ИБ хранителя имейте ввиду, что максимальный размер в файловой базе 1С одной таблицы может достигать 4 Гб.

Импорт данных из старого журнала регистрации из БД MS SQL

Откройте информационную базу хранителя и запустите обработку:

  

67.png

В обработке укажите параметры доступа к старому журналу в БД MS SQL:

  

68.png

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

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

Обновление конфигурации «Хранитель журнала регистрации»

Информационная база «Хранитель журнала регистрации» обновляется абсолютно аналогично любой другой конфигурации 1С.

 

1.       Запустите систему 1С:Предприятие «Хранитель журнала регистрации» в режиме "Конфигуратор".

2.       Обязательно сделайте архивную копию вашей информационной базы! Для этого надо в меню Администрирование выбрать пункт "Выгрузить информационную базу" и ввести имя файла выгрузки. Этот файл надо сохранить в надёжном месте.

3.       В режиме "Конфигуратор" откройте конфигурацию, для этого в меню "Конфигурация" выберите пункт "Открыть конфигурацию".

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

5.       В диалоге выбора обновления в качестве источника обновления укажите "Выбор файла обновления", после чего выберите нужное обновление в каталоге "c:\Users\ИмяПользователя\AppData\Roaming\1C\1Cv82\tmplts\journext\каталог версии\".

6.       В окне "Обновление конфигураций" нажмите кнопку "OK" для продолжения обновления конфигурации.

7.       На вопрос об обновлении конфигурации базы данных ответьте "ДА".

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

9.       Важно! После каждого обновления надо хотя бы 1 раз запускать 1С в режиме 1С:Предприятие. Именно после каждого, т.к. поставили одну версию – запустили в режиме предприятия, потом поставили следующую версию – запустили в режиме предприятия и т.д.

Запуск регламентного задания по сжатию из командной строки

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

Отключение полнотекствого поиска

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

 

Сначала откроем команду «Все функции». Сделать это можно в меню:

2.jpg

Далее включим галочку:

3.jpg

Теперь откроем сами настройки:

4.jpg

Отключим полнотекстовый поиск:

5.jpg

Вопросы

Перечислим часто возникающие вопросы.

 

Что делать, если события не попадают из рабочей информационной базы в Хранитель?

Этот вопрос часто задают те, кто устанавливают подсистему и не понимают почему события не выгружаются в Хранитель.
Рассмотрим основные причины такого поведения:

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

Если появилась надпись "Все параметры подключения установлены правильно", то переходим к следующему пункту, если нет, то смотрим статью 
Не работает проверка соединения с конфигурацией «Хранитель» из подсистемы или ошибка «Недопустимая строка с указанием класс"

2. Заходим на закладке "Мониторинг журнала" и нажимаем кнопку "Перенос во внешнюю ИБ", попробуем вручную перенести события. Будет большая пауза в этот момент открываем конфигурацию "Хранитель" и смотрим увеличивается ли количество событий в "Хранителе" периодически нажимая кнопку "Обновить"
Просмотр количества событий в Хранителе

Если количество увеличивается, но автоматически ничего не переносится, тогда переходим к следующему пункту, иначе, надо вернутся к пункту 1. 

3. Если вручную все переносится, а программно (с помощью регламентного задания) нет, то необходимо проверить параметры уникальности.
Они предназначены для того, чтобы события из копий не попадали в хранитель.
Перво-наперво проверьте расписание регламентного задания "(ВН) Перенос кэша журнала регистрации", сделать это можно в настройках конфигурации в режиме предприятия, либо через консоль регламентных заданий. Если расписание в норме, попробуйте вручную запустить регламентное соответствующей кнопкой.
Перейдите в стандартный журнал регистрации и найдите в нем строки по запуску этого регламентного задания. Если обмен не пошел, то там будет информация о причинах того, почему не работает автоматическая выгрузка событий.
Отключите параметры уникальности и снова попробуйте запустить регламентное или дождаться его выполнения. Если после этого обмен был успешным, то необходимо настроить параметры уникальности.
Для этого перечилите все возможные варианты именования сервера 1С в строке "Список серверов" и отделите их друг от друга либо точкой с запятой, либо символом вертикального слеша "|", например:

server1с;192.168.1.10;server1c.local;server1с:1591;...

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

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

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

Не переносятся данные. Ошибки V83.COMConnector

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

Как правило причин не много. Перечислим основные ошибки и причины почему не работает COM-соединение.

1. Не зарегистрирован comcomcntr.dll - библиотека платформы, которая отвечает за создание COM-объектов. Вот инструкция как ее установить. Инструкция работает для компьютеров с не серверными ОС.
2. Сервер x64 и на нем нельзя зарегистрировать библиотеку как в п.1 Тогда зарегистрируем все самостоятельно. Необходимо воспользоваться инструкцией.
3. Не проходят параметры уникальности. Настройте их правильно.

Установил журнал регистрации но в журнал попадают только "Начало сеанса" и "Завершение сеанса" и событие "Физическое удаление"

Если по какой-то причине ничего не регистрируется смотрите в стандартный журнал регистрации, ошибки регистрации будут отображены там.
Скорее всего дело в том, что у конфигурации режим разделения блокировки стоит Автоматический, а у регистра, куда пишутся события, стоит Управляемый.
Что нужно сделать, чтобы решить проблему?
  1. Измените в регистре режим блокировок на Автоматический для регистр сведений "внКэшЖурналаРегистрации"
  2. В процедуре модуля внЖурналРегистрацииСервер измените процедуру удалив блок как на скриншоте (может чуть-чуть отличаться код, надо удалить блокировку):
Что удалить


В хранитель был перенесен лишний объект/объекты. Как мне его удалить?

Действительно, такое бывает очень часто. Настроили журнал, сделали заполнение, а потом поняли, что какой-то объект или целую группу объектов регистрировать не нужно (занимает место, но данные по этим событиям не используются).
Для удаления событий по этому объекту необходимо открыть ИБ "Хранитель журнала регистрации" перейти в подсистему "Внешний журнал регистрации" > Настройки, закладка "Настройки хранения и обработки", щелкнуть правой кнопкой по нужному объекту и выбрать "Удалить данные".
Удаление данных из хранителя

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

Да, конечно, это возможно. Перед удалением в информационной базе в режиме предприятия никто не должен работать.

Для удаления сделайте отбор по подсистеме «внЖурналРегистрации» как на рисунке ниже:

 

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

После удаления всех этих объектов сохраните конфигурацию (Ctrl+S) и обновите конфигурацию базы данных (F7).

После этого журнал будет удален из информационной
базы.

При режиме управления блокировкой данных в транзакции по умолчанию: Автоматический и управляемый возникают ошибки. Почему?

Согласно https://its.1c.ru/db/metod8dev#content:5839:hdoc
1) Существующая блокировка Управляемая <=> Регистр сведений Управляемый режим
Проводится документ например в управляемой транзакции.

Начинаемая транзакция будет выполнена в управляемом режиме

2) Существующая блокировка Автоматическая <=> Регистр сведений Управляемый режим

Начинаемая транзакция будет выполнена в автоматическом режиме

3) Существующая блокировка Автоматическая <=> Регистр сведений Автоматический режим

Начинаемая транзакция будет выполнена в автоматическом режиме

4) Существующая блокировка Управляемая <=> Регистр сведений Автоматический режим

Будет вызвана исключительная ситуация


Фиксирование данных в кэше идет по следующему алгоритму: объект изменения начинает транзакцию со своим типом блокировки, в работающей транзакции, срабатывает подписка на событие и фиксирует изменение в кэш уже в своей блокировке (см пункты выше). Проблема возникает только там, где стоит режим блокировок в начале транзакции "Автоматический" в объектах.
При этом обратите внимание, что вне зависимости от того, какой режим транзакций будет у регистра кэша, будет возникать проблема.
Если регистр кэша будет с автоматическим режимом, то если у объекта источника изменений режим управления транзакциями стоит Управляемый, то будет исключительная ситуация, если же регистр будет на управляемых блокировках, то если у объекта источника изменений режим управления транзакциями будет стоять Автоматический, то транзакция будет так же в автоматической блокировке и вот здесь у Вас проблемы с транзакциями. Что имеем? Без перевода объектов источников изменений в управляемый режим управления блокировками ничего, к сожалению, не решить. Подсистема здесь не играет никакой роли, все транзакции начинаются с объектов конфигурации, а значит нужно менять режим у них.

Как можно выйти из сложившейся ситуации:

1) Регистр сведений внКэшЖурналаРегистрации, должен быть на управляемых блокировках.
2) Оставить регистрацию в настройках подсистемы объектов только с управляемыми блокировками.
3) Постепенно осуществить перевод тех объектов, которые на автоматических блокировках и которые необходимо фиксировать на управляемый режим (объектов и регистров с ними связанными)
4) После перевода на управляемые блокировки включить их в регистрируемые объекты подсистемы.

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

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

Частый вопрос, который возникает у пользователей. На самом деле тут важно понимать, как записывается событие при изменении объекта. Схема записи следующая:
1) Проверка входит ли изменяемый объект в список регистрируемых, если не входит не записываем событие
2) Проверка есть ли у пользователя роль "(ВН) Не фиксировать изменения журнала регистрации", если есть не записываем событие
3) Проверка подходят ли параметры уникальности текущей информационной базы, если не подходят не записываем.

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

Опять же, тут все достаточно просто. Параметры уникальности дают нам проверку следующего вида "А это изменение не в копии базы?", если да то понятное дело его фиксировать не нужно, чтобы события копии не попадали в хранитель.
Теперь по настройки этого механизма. Самое простое, если бьетесь и не можете решить - просто отключите проверку уникальности и все.
Если же вы хотите настроить все "по уму", то первое, что нужно сделать: соберите все возможные представления сервера 1С для ИБ, которые вы подключаете пользователям. Да, они могут быть разными. Базу можно подключить и в качестве сервера 1С задать "server1c" (без кавычек), а можно "10.0.0.5" (ip-адрес сервера 1С), а можно "server1c:1541", "server.local" и т.п. Заметьте, что если в качестве сервера написать один из подобные вариантов - это будет работать и пользователи будут подключаться к базе. Но т.к. параметры уникальности допустим прописаны: "server1c" (без кавычек), а пользователю на его рабочем месте база подключена как "10.0.0.5" (без кавычек), то подсистема думает, что параметр уникальности не совпадает для этого пользователя и для этой базы и не записывает события.
Составьте строку подключения представления серверов (регистр букв не имеет значения) и запишите их, либо через запятую в поле настройки, либо с использованием символа вертикального слеша "|" (без кавычек). Т.е. для примера, который мы указали выше строка будет выглядеть вот так:
server1c|10.0.0.5|server1c:1541|server1c.local 

Параметры уникальности

А вот настройка в программе.

Нужно ли отключать стандартный журнал регистрации?

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

Перенос данных из кэша подсистемы в «Хранитель» осуществляется очень долго

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

Какой оптимальный срок хранения событий? Мнение авторов.

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

У нас есть свое мнение на этот счет. Зачем в базе торговли, где, допустим, включен авто запрет редактирования данных, хранить данные о том, что было 2 года назад? Эти данные явно лишние! Никого не будет интересовать, кто был автором документа «Перемещение товаров» 2 года назад. Подумайте, что точно не пригодиться и смело настройте очистку этих объектов. Почти всегда важными являются сведения о событиях, которые были совершены в течении последнего месяца, остальное обычно не важно.

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

Почему данные из кэша рабочей ИБ не переносятся в ИБ «Хранитель»

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

 

1)      Нет возможности соединиться с базой Хранителя

 

Либо база не доступна, либо не работает на сервере Com-соединение. По настройке Com-соединения см. тему Ошибка V82.COMConnector на сервере 64. Решение проблемы

 

2)      Не подходят параметры уникальности информационной базы

 

Параметры уникальности предназначены для защиты вашего хранителя от баз дубликатов. Действительно, что, если у вас есть тестовая база, на которой программисты 1С тестируют что-то и потом их изменения попадают в хранитель. На пути дубликатов баз как раз и появляется наш механизм уникальности. В настройках мы вносим список серверов и имя базы. При переносе данных в хранитель происходит проверка имени базы и представления сервера, если что-то не совпадает, то перенос не осуществляется. Часто проблемы из-за того, что возможные имена сервера заданы не верно. Дело в том, что могут отличаться представления сервера на клиенте и в регламентном задании по переносу. Например, у вас база хранителя подключена к серверу: 192.168.1.10, а сервер ее видит вот так: serverdb (имя вашего сервера 1С), или вообще вот так: serverdb.local (если в домене).

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

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

Не работает проверка соединения с конфигурацией «Хранитель» из подсистемы или ошибка «Недопустимая строка с указанием класса»

Так может случиться, что связь с хранителем может не устанавливаться по причине того, что в Windows не установлен класс ComConnector. Для регистрации выполните команду в системе:

 

Regsvr32 “c:\Program Files (x86)\1cv8\8.3.7.1759\bin\comcntr.dll

(версию 1С нужно изменить на вашу)

 

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

В стандартном журнале регистрируются ошибки фонового задания подсистемы

Если появились ошибки типа:

 

{ОбщийМодуль.внЖурналРегистрации.Модуль(2229)}: Ошибка при вызове метода контекста (Удалить) Объект.Удалить();

по причине: Ошибка использования Менеджера блокировок Автоматический режим блокировки недопустим в этой транзакции.

 

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


69.png

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

Что делать, если очень быстро растет база данных журнала в «Хранителе»?

Для того, чтобы размер журнала регистрации рос медленнее, к его настройке надо отнестись очень серьезно. Не правильная настройка журнала может увеличивать ИБ Хранителя очень серьезно и необоснованно. Для этого выполните ряд требований:

  1. Отключите, если это не важно, кто когда вышел и зашел в ИБ (входы/выходы), если эта информация не актуальна для Вас.
  2. Надо понимать, что ИБ хранителя журнала может очень быстро расти и в том случае, если происходит интенсивный ввод данных и в больших количествах. Если допустим Ваша информационная база 1С работает 24/7 и в онлайн вводят документы сразу 50 пользователей, а основная база достигает 50 Гб, то не стоит удивляться, если журнал будет в 10-20 раз больше, т.к. в основную базу записывается только один объект и не важно сколько раз Вы будете его менять, а в журнал пишутся все события при записи объекта, т.е. любой чих, грубо говоря. Это, в общем, не рекомендация, а констатация факта. Не требуйте маленького размера от Хранителя, если вы хотите хранить все изменения, но при этом у Вас огромная рабочая база и высокая интенсивность работы.
  3. Для решения проблемы уменьшения размера информационной базы хранителя настройте хранитель таким образом, чтобы он очищал старые и не нужные для вас события. Можно задать период хранения и если для события период будет превышен, то событие будет удалено, что приведет к уменьшению размера ИБ хранителя. Как настроить удаление см. главу выше.
  4. Выключите не нужные регистры сведений, фиксируйте изменения только важных регистров! Это очень больной вопрос. Если убрать регистрацию не нужных регистров Вы серьезно сэкономите объем в ИБ.
  5. Кроме регистров можно так же не фиксировать изменения не нужных объектов других типов. Например, в типовых конфигурациях есть куча системных справочников: рабочие места, профили пользователей и т.д.
  6. В настройках подсистемы в рабочей ИБ не фиксируйте изменения реквизитов с типом "ХранилищеЗначения". Как правило там хранятся файлы, макеты и т.д. Все то, что большое и часто вовсе не обязательно изменения этих реквизитов фиксировать.
  7. Храните только изменения объектов (в настройках Хранителя укажите это).
  8. Уменьшите интервал хранения измененных и событий без изменений (открыл, нажал "Записать"). События без изменений, можно хранить не больше
Это краткий список правил. Конечно, не нужно с фанатизмом отключать лишнее. Если Вам что-то нужно, то фиксируйте это без проблем, но будьте готовы к тому, что Хранитель будет быстро расти и увеличиваться.

Что делать, если после внедрения журнала, база 1С стала работать очень медленно?

Данная проблема появляется в основном если используется «слабое железо», которое и до внедрения журнала работало не особенно быстро, а после внедрения стало еще медленней. Стоит понимать, что «добавление» дополнительного функционала никогда не идет на пользу производительности, она всегда будет падать, так как от конфигурации требовали раньше столько, а после добавления чего-нибудь, столько же и еще чуть-чуть. Поэтому конфигурация после внедрения подсистемы, априори будет работать медленней чем без нее. Другой вопрос насколько медленней… Если время записи упало с 0.1 сек. до 0.5 сек., то не существенно и субъективно Вы не почувствуете разницу. Если с 2 сек. до 5 сек., то это будет заметно.

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

Итак, проблема есть, что же делать и как ее решить? Приведем основные моменты по оптимизации скорости работы журнала:

1. Отключите фиксирование входов/выходов пользователей.

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

3.Особое внимание уделите регистрации регистров сведений. Старайтесь чтобы в настройках подсистемы фиксировались изменения как можно меньшего количества регистров сведений. А еще лучше отключить в случае если информационная база 1С работает очень медленно регистрирование изменений всех регистров сведений. Зачастую пользователи говорят, а как фиксировать вообще все? В связи с этом вопрос: вы хотите регистрировать служебные регистры, которые не меняются пользователями, а только системой? Пользователь говорит: нет… а зачем тогда регистрировать изменения этих регистров? Или зачем регистрировать изменения регистра «Адресный классификатор»? Это огромные регистры, которые не дадут нам информации ни о чем. Отключите их регистрацию смело.

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

5. В ИБ «Хранитель журнала регистрации» так же настройте регламентные так, чтобы они не влияли на производительность сервера. Тут есть два пути. Первый – уменьшить интервал работы регламентных заданий. Тогда малые порции будут обрабатываться за маленькое время, что в целом не повлияет на производительность. Второй – перенести работу регламентных в то время, когда с ИБ работает мало пользователей, или вообще не работает.

6. В настройках на вкладке «Дополнительно» установите «Период просмотра в журнале по умолчанию» в «За последний день» или «За последнюю неделю». Это позволит открывать журнал регистрации быстрее.

7. Пройдите в настройках по метаданным и удалите из логируемых те реквизиты объектов, которые могут содержать данных больших объемов и которые могут серьезно увеличить информационную базу «Хранителя» (хранилища значений, файлы, тексты, картинки и т.п.). Если эти данные не нужны, то отключите эти реквизиты убрав их из регистрации. Для хранилищ значений в настройках регистрируемых объектов есть специальная кнопка, которая отключит реквизиты, которые содержат тип "ХранилищеЗначения".


 

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


Дополнительные сведения

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

Для партнеров действуют специальные скидки!

Контакты

ИП Барилко Виталий Викторович ©

Сайт: http://softonit.ru

E-mail: support@softonit.ru

ICQ: 335-655-187

Skype: barilkovetal

Телефон: +7 (952) 865-58-62

 

Внимание! Если возникла проблема или пожелание опубликуйте ее в тикет-системе

 Начать курс обучения1